why does venv reference different python version - python

I followed djangogirls tutorial to get started with django and had everything working. Once I finished the basic tutorial, everything in working order, I decided to go through the steps again to make something new and become more familiar with using git, django, venv, etc.
fyi - I am on windows 10 and have python 2.7 and python 3.5 installed. I am using python 3.5.2 with django 1.10.4.
steps:
>mkdir v2
>cd v2
>"d:/python 3.5.2/python" -m venv myenv
>cd myenv/scripts/activate
(myenv) python -m pip install -U pip
for some reason this is the only way I was able to upgrade pip this time around
(myenv) d:/v2/myenv/scripts> pip install django~=1.10.0
(myenv) d:/v2/myenv/scripts> django-admin.py startproject mysite
This is where the magic doesn't happen:
d:\v2>django-admin.py startproject mysite2
Traceback (most recent call last):
File "D:\v3\myenv\Scripts\django-admin.py", line 2, in <module>
from django.core import management
File "C:\Python27\lib\site-packages\django\core\management\__init__.py", line 10, in <module>
from django.apps import apps
File "C:\Python27\lib\site-packages\django\apps\__init__.py", line 1, in <module>
from .config import AppConfig
File "C:\Python27\lib\site-packages\django\apps\config.py", line 4, in <module>
from django.core.exceptions import AppRegistryNotReady, ImproperlyConfigured
File "C:\Python27\lib\site-packages\django\core\exceptions.py", line 5, in <module>
from django.utils.encoding import force_text
File "C:\Python27\lib\site-packages\django\utils\encoding.py", line 11, in <module>
from django.utils.six.moves.urllib.parse import quote, unquote
File "C:\Python27\lib\site-packages\django\utils\six.py", line 92, in __get__
result = self._resolve()
File "C:\Python27\lib\site-packages\django\utils\six.py", line 160, in _resolve
module = _import_module(self.mod)
File "C:\Python27\lib\site-packages\django\utils\six.py", line 82, in _import_module
__import__(name)
File "C:\Python27\lib\urllib.py", line 26, in <module>
import socket
File "C:\Python27\lib\socket.py", line 47, in <module>
import _socket
ImportError: Module use of python35.dll conflicts with this version of Python.
As far as I am aware, I followed the same steps. I am not sure why the djano installed in my venv would be referencing python 2.7, since I thought if created my venv from the python 3.5.2 dir it would reference that version, along with anything I used pip for within that dir?
Can someone help me find what I am missing here? ty.

By default virtualenv uses python2. If you want to use python3, you have to specify it explicitly.
Run following command to setup virtualenv with python3:
virtualenv -p python3 envname

While in "Python 3.5.2/scripts" I ran:
virtualenv d:/<dirname>
Everything after(django-admin.py startproject projectname) worked correctly. Still not sure what went wrong here but maybe this helps someone else...

Related

ImportError when trying to use Django

apologies if this question has been asked a ton, I'm sure it has, and I've been trying for days to figure this out, but I can't wrap my head around it. I've been developing in Python for over 1.5 years, so I'm not a complete beginner.
I can't get Django to work in my command prompt. An example is, when I try to use py .\manage.py makemigrations this is what I get:
Traceback (most recent call last):
File ".\manage.py", line 11, in main
from django.core.management import execute_from_command_line
ModuleNotFoundError: No module named 'django'
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File ".\manage.py", line 22, in <module>
main()
File ".\manage.py", line 13, in main
raise ImportError(
ImportError: Couldn't import Django. Are you sure it's installed and available on your PYTHONPATH environment variable? Did you forget to activate a virtual environment?
Now, I can see what the error says. The thing is my virtual environment is activated and it has Django installed, as seen here. Moreover, even if I executed outside my venv, it still doesn't work, even though I have all necessary Python directories in my PATH, as seen here.
I have verified that django-admin is installed on both my venv and my system, as well as Django itself, since I can import it on my Python Console. The version is 3.1.7. I have also tried reinstalling Django and it didn't work.
Another error I get, when I attempt to run Django console through PyCharm is this:
Traceback (most recent call last):
File "<input>", line 6, in <module>
File "C:\Users\user\AppData\Roaming\Python\Python39\site-packages\django\__init__.py", line 19, in setup
configure_logging(settings.LOGGING_CONFIG, settings.LOGGING)
File "C:\Users\user\AppData\Roaming\Python\Python39\site-packages\django\conf\__init__.py", line 82, in __getattr__
self._setup(name)
File "C:\Users\user\AppData\Roaming\Python\Python39\site-packages\django\conf\__init__.py", line 63, in _setup
raise ImproperlyConfigured(
django.core.exceptions.ImproperlyConfigured: Requested setting LOGGING_CONFIG, but settings are not configured. You must either define the environment variable DJANGO_SETTINGS_MODULE or call settings.configure() before accessing settings.
I hope this helps you come up with any idea. Could anyone please share any insight on why I'm getting this? I would greatly appreciate it.
Edit: I have installed Django through PIP:
py -m pip install django
py -m pip install djangorestframework
py -m pip install django-admin
Also, Django is imported correctly from the Python Console within the venv:
>>> import django
>>> django
<module 'django' from 'C:\\Users\\user\\AppData\\Roaming\\Python\\Python39\\site-packages\\django\\__init__.py'>
in cmd to create a virtualenv
python -m venv virtualenv_name
to enable virtualenv
virtualenv_name\scripts\activate.bat
then
pip install django
and to create a project
django-admin startproject projectname
to run the project
cd projectname
python manage.py runserver

I'm not able create virtual environment using virtualenv

C:\Users\NAVEEN\Desktop\Demo>virtualenv venv
Traceback (most recent call last):
File "c:\users\naveen\appdata\local\programs\python\python38\lib\runpy.py", line 192, in _run_module_as_main
return _run_code(code, main_globals, None,
File "c:\users\naveen\appdata\local\programs\python\python38\lib\runpy.py", line 85, in _run_code
exec(code, run_globals)
File "C:\Users\NAVEEN\AppData\Local\Programs\Python\Python38\Scripts\virtualenv.exe\__main__.py", line 4, in <module>
File "c:\users\naveen\appdata\local\programs\python\python38\lib\site-packages\virtualenv\__init__.py", line 3, in <module>
from .run import cli_run
File "c:\users\naveen\appdata\local\programs\python\python38\lib\site-packages\virtualenv\run\__init__.py", line 12, in <module>
from .plugin.activators import ActivationSelector
File "c:\users\naveen\appdata\local\programs\python\python38\lib\site-packages\virtualenv\run\plugin\activators.py", line 6, in <module>
from .base import ComponentBuilder
File "c:\users\naveen\appdata\local\programs\python\python38\lib\site-packages\virtualenv\run\plugin\base.py", line 7, in <module>
from importlib.metadata import entry_points
ModuleNotFoundError: No module named 'importlib.metadata'
In Python 3.6+, the pyvenv module is deprecated.Your python interpreter version is 3.8.
Use the following one-liner instead:
python3 -m venv <myenvname>
Python already ships with its builtin "virtualenv" called venv since
version 3.3. You no longer need to install or download the virtualenv
scripts for Python 3.3+.
Refer the doc for more and Another stackOverflow Answer
You want to write it like this:
python -m venv {virtualenv}
replace '{virtualenv}' with the name you want your virtual environment to have.
Fisrt install virtualenv
Using comand
pip install virtualenv
Or
pip3 install virtualenv(for linux)
Then you can create a venv
You can check version ov virtualenv using comand
virtualenv --version

Python error in Vim when run inside a 3.5.3 virtualenv

I have multiple Python versions installed with pyenv on Ubuntu 16.04. I create virtual environments to work with projects using different versions with pipenv. However, for Python 3.5.x only I get errors like this when I try to edit a file with Vim 8 (installed via the PPA) in an activated virtualenv:
"test.py" 49L, 1434C
Error detected while processing function jedi#init_python[4]..<SNR>48_init_python[27]..jedi#setup_python_imports:
line 25:
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/home/user/.local/share/virtualenvs/test-AYf6DmHL/lib/python3.5/imp.py", line 19, in <module>
from importlib._bootstrap import _ERR_MSG, _exec, _load, _builtin_from_name
File "/home/user/.local/share/virtualenvs/test-AYf6DmHL/lib/python3.5/importlib/__init__.py", line 57, in <module>
import types
File "/home/user/.local/share/virtualenvs/test-AYf6DmHL/lib/python3.5/types.py", line 166, in <module>
import functools as _functools
File "/home/user/.local/share/virtualenvs/test-AYf6DmHL/lib/python3.5/functools.py", line 23, in <module>
from weakref import WeakKeyDictionary
File "/home/user/.local/share/virtualenvs/test-AYf6DmHL/lib/python3.5/weakref.py", line 12, in <module>
from _weakref import (
ImportError: cannot import name '_remove_dead_weakref'
The issue seems to affect all python related Vim plugins. With other Python versions (e.g. 3.6.x, 3.7.x) this does not occur. What may be causing this issue?
Update: It seems that when I run Vim inside a 3.5.x virtualenv, the Vim's interpreter's sys.path gets updated somehow. For example, this is the output of :py3 import sys; print(sys.path) inside a 3.6.0 virtualenv:
['/usr/lib/python35.zip', '/usr/lib/python3.5', '/usr/lib/python3.5/plat-x86_64-linux-gnu', '/usr/lib/python3.5/lib-dynload', '/usr/local/lib/python3.5
/dist-packages', '/usr/lib/python3/dist-packages', '_vim_path_']
And this is for 3.5.3:
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/home/testuser/.local/share/virtualenvs/venv-3.5-8feRiT5s/lib/python3.5/imp.py", line 19, in <module>
from importlib._bootstrap import _ERR_MSG, _exec, _load, _builtin_from_name
File "/home/testuser/.local/share/virtualenvs/venv-3.5-8feRiT5s/lib/python3.5/importlib/__init__.py", line 57, in <module>
import types
File "/home/testuser/.local/share/virtualenvs/venv-3.5-8feRiT5s/lib/python3.5/types.py", line 166, in <module>
import functools as _functools
File "/home/testuser/.local/share/virtualenvs/venv-3.5-8feRiT5s/lib/python3.5/functools.py", line 23, in <module>
from weakref import WeakKeyDictionary
File "/home/testuser/.local/share/virtualenvs/venv-3.5-8feRiT5s/lib/python3.5/weakref.py", line 12, in <module>
from _weakref import (
ImportError: cannot import name '_remove_dead_weakref'
['/must>not&exist', '/home/testuser/.local/share/virtualenvs/venv-3.5-8feRiT5s/lib/python35.zip', '/home/testuser/.local/share/virtualenvs/venv-3.5-8feRiT5s/li
b/python3.5', '/home/testuser/.local/share/virtualenvs/venv-3.5-8feRiT5s/lib/python3.5/plat-x86_64-linux-gnu', '/home/testuser/.local/share/virtualenvs/venv-3.
5-8feRiT5s/lib/python3.5/lib-dynload', '/home/testuser/.pyenv/versions/3.5.7/lib/python3.5', '/home/testuser/.local/share/virtualenvs/venv-3.5-8feRiT5s/lib/pyt
hon3.5/site-packages']
The issue can be reproduced in a ubuntu:16.04 docker container.
Debian Bug report logs - #852163: python3.5-minimal wont configure demonstrates that this error (for Python 3.5 and Python 3.6) is due to another incompatible installation of Python in /usr/local.
Some further digging with another user in #debian who was experiencing this
problem indicated that it was related to a locally installed
/usr/local/bin/python3.5. The stdlib in /usr/lib/python3.5 is picked up by the
/usr/local/bin/python3.5 but is not compatible with it, resulting in the
stacktrace shown.
Removing /usr/local/bin/python3* and all traces of that installation from
/usr/local/lib (plus other associated tools) solved this problem for the user
I was helping in #debian.
-- Stuart Prescott (link)
The problem is caused by the system installed python, which conflicts with personally installed python.
It could be the case that other python versions are interfering here. Do you have a PYTHONPATH set?
echo $PYTHONPATH
If it is set you could try to unset it. It's usually not needed when using virtual environments.
Try running python with sudo. I think the python which comes with OS needs to run with admin privilege.

Django traceback error: No module named 'repr'

I have been using django perfectly sans problems until today. It was giving me the error on an existing project but I have recently tried to create a new project and I stil get the same errors.
I am on ubuntu 14.04, django 1.7, I use virtualenv and python 3 (alhtough I have tried using a python2 env also).
I get this error:
ubuntuuser#computer:~/tmp$
ubuntuuser#computer:~/tmp$ mkvirtualenv djerror
New python executable in djerror/bin/python
Installing setuptools, pip...done.
cd (djerror)ubuntuuser#computer:~/tmp$ cd borrar/
bin/ borrar/ include/ lib/ local/
(djerror)ubuntuuser#computer:~/tmp$ django-admin.py startproject djerror
(djerror)ubuntuuser#computer:~/tmp$ cd djerror/
(djerror)ubuntuuser#computer:~/tmp/djerror$ ls
djerror manage.py
(djerror)ubuntuuser#computer:~/tmp/djerror$ python manage.py runserver
Traceback (most recent call last):
File "manage.py", line 8, in <module>
from django.core.management import execute_from_command_line
File "/usr/local/lib/python2.7/dist-packages/django/core/management/__init__.py", line 1, in <module>
import collections
File "/usr/local/lib/python3.4/collections/__init__.py", line 17, in <module>
from reprlib import recursive_repr as _recursive_repr
File "/usr/local/lib/python2.7/dist-packages/reprlib.py", line 3, in <module>
from repr import *
ImportError: No module named 'repr'
(djerror)ubuntuuser#computer:~/tmp/djerror$
here is another method which gfives me the same error:
ubuntuuser#computer:~/tmp$ virtualenv djerror2
New python executable in djerror2/bin/python
Installing setuptools, pip...done.
ubuntuuser#computer:~/tmp$ cd djerror
ubuntuuser#computer:~/tmp/djerror$ cd ..
ubuntuuser#computer:~/tmp$ cd djerror2
ubuntuuser#computer:~/tmp/djerror2$ . bin/activate
(djerror2)ubuntuuser#computer:~/tmp/djerror2$ pip list
awsebcli (3.0.10)
cement (2.4.0)
Django (1.7.5)
django-bootstrap3 (5.1.1)
django-braces (1.4.0)
...
stevedore (1.2.0)
virtualenv (12.0.6)
virtualenv-clone (0.2.5)
virtualenvwrapper (4.3.2)
(djerror2)ubuntuuser#computer:~/tmp/djerror2$ django-admin.py startproject anothertest
(djerror2)ubuntuuser#computer:~/tmp/djerror2$ cd anothertest/
(djerror2)ubuntuuser#computer:~/tmp/djerror2/anothertest$ python manage.py runserver
Traceback (most recent call last):
File "manage.py", line 8, in <module>
from django.core.management import execute_from_command_line
File "/usr/local/lib/python2.7/dist-packages/django/core/management/__init__.py", line 1, in <module>
import collections
File "/usr/local/lib/python3.4/collections/__init__.py", line 17, in <module>
from reprlib import recursive_repr as _recursive_repr
File "/usr/local/lib/python2.7/dist-packages/reprlib.py", line 3, in <module>
from repr import *
ImportError: No module named 'repr'
(djerror2)ubuntuuser#computer:~/tmp/djerror2/anothertest$
What gives?
edit:
This is what I have at the bottom of ~/.bashrc. I have done some changes ever since I installed ubuntu, but I recently changed the bottom two lines for virtualenvwrapper.
alias python='python3'
export WORKON_HOME=$HOME/.virtualenvs
source /usr/local/bin/virtualenvwrapper.sh
I think the rest of the file is untouched.
After some fiddling around (and especially after reading Brandon and Daniel's comments) I spotted the problem.
I had done something wrong at some point in time which wasn't causing problems until today. The thing is python was loading some modules from the python2 path and others from the python3 path.
To fix it I did the following:
remove the python3 alias
to do this correctly you have to rm python from /usr/bin/ and then point it to python3 sim link
purge remove python3 and reinstall it.
reinstall all packages associated to python3, like pip and others
Only then did everything work, though I may have gone overboard, I preferred to do it like this just to be sure.

ubuntu ImportError: cannot import name MAXREPEAT

Upgrade to 13.04 has totally messed my system up .
I am having this issue when running
./manage.py runserver
Traceback (most recent call last):
File "./manage.py", line 8, in <module>
from django.core.management import execute_from_command_line
File "/home/rats/rats/local/lib/python2.7/site-packages/django/core/management
/__init__.py", line 4, in <module>
from optparse import OptionParser, NO_DEFAULT
File "/usr/lib/python2.7/optparse.py", line 77, in <module>
import textwrap
File "/usr/lib/python2.7/textwrap.py", line 10, in <module>
import string, re
File "/usr/lib/python2.7/string.py", line 83, in <module>
import re as _re
File "/home/rats/rats/lib/python2.7/re.py", line 105, in <module>
import sre_compile
File "/home/rats/rats/lib/python2.7/sre_compile.py", line 14, in <module>
import sre_parse
File "/home/rats/rats/lib/python2.7/sre_parse.py", line 17, in <module>
from sre_constants import *
File "/home/rats/rats/lib/python2.7/sre_constants.py", line 18, in <module>
from _sre import MAXREPEAT
ImportError: cannot import name MAXREPEAT
this is happening for both the real environment as well as for virtual environment .
i tried removing python with
sudo apt-get remove python
and sadly it has removed everything .
now google chrome does not show any fonts .
i am looking for getting things back to work .
help is needed for proper configuring it again.
If you are using virtualenvwrapper then you can recreate the virtualenv on top of the existing one (with no environment currently active):
mkvirtualenv <existing name>
which should pull in the latest (upgraded) python version from the system and fix any mismatch errors.
You don't need to recreate the environment.
You can upgrade the virtualenv running this command:
virtualenv /PATH/TO/YOUR_OLD_ENV
YOUR_OLD_ENV folder will be properly upgraded to the version 2.7.4.
I have just solved that problem on my machine.
The problem was that Ubuntu 13.04 use python 2.7.4. That makes conflict with the Python version of the virtualenv.
What I do was to re-create the virtualenv with the new version of python. I think it's the simplest way, but you can try to upgrade the python version without re-creating all of the virtualenv.

Categories

Resources