virtualenv when running on my computer is not using the verison of python3 that I expect. I want it to use the same version as that returned by which python - is there a way of changing the default version of python that virtualenv uses.
I can use the -p flag in a particular invocation, but I can't find a way of changing the default in the man page.
There is an obvious terrible work around with bash aliases but this is terrible.
virtualenv defaults to the python it was run with. I do this on my machine with ... more virtualenvs!
step 1: create a virtualenv at a ~well known location in your home directory. I use ~/opt/venv. make sure to use the python you want to be the default (in my case, python3.9)
virtualenv ~/opt/venv -p python3.9
step 2: install virtualenv into that virtualenv
~/opt/venv/bin/pip install virtualenv
step 3: put that virtualenv onto your PATH (for example, I have ~/bin on the path, you might have ~/.local/bin or some other directory
ln -s ~/opt/venv/bin/virtualenv ~/bin/
now when you make virtualenvs, it will use this executable and default to the python you picked
$ which virtualenv
/home/asottile/opt/venv/bin/virtualenv
Related
I have a problem with Linux in PC. I installed python3.8. I want work with python 3. When I create a virtualenv file it gets created with python2, but I don't want work with python2. How can I enable python2?
You can set a python version while creating a new virtual environment using the -p flag.
virtualenv -p python3.8 my-env-name
Perhaps you can try to locate the location of the python version you want to use the interpreter of (eg. get its path through which python3). Once obtained the path you can create the enviroment specifying the location of the interpreter you want to use for that virtual environment virtualenv -p /usr/bin/python3.6 venv
I had this in my .bash_profile:
PATH="/Library/Frameworks/Python.framework/Versions/3.4/bin:${PATH}"
And I thought that if I just change it to this:
PATH="/Users/myusername/.pyenv/versions/3.7.2/bin:${PATH}"
Then virtualenvwrapper should simply use this as the new "source" Python to use. But that breaks it and issues a warning about the Python version not having any "virtualenvwrapper hooks".
How can I change the version mkvirtualenv installs by default? I'm looking for this to be a one-time change. I'm aware of the -p flag but don't want to have to specify it every time I create a virutalenv.
Solution 1:
alias vv="virtualenvwrapper -p python3.7"
Solution 2:
set python3.7 as your default version, for example:
export py_which=`which python`
sudo rm $py_which
sudo ln -s `which python3.7` $py_which
Apparently the code in my question works, I just needed to install virtualenvwrapper for that specific python env.
For simplicity, I'm now prepending this python version to my path as below, so I can easily change the path in the future:
export PYTHON_PATH_LATEST="/Users/myusername/.pyenv/versions/3.7.2/bin"
PATH="${PYTHON_PATH_LATEST}:${PATH}"
As an added bonus, this is now also the python version pipenv will choose by default.
I've added the following lines to my bash, but mkproject keeps creating python 2.7 folders into the virtual env, therefore I still need to use -p python3, which I'd like to not have to do.
export VIRTUALENVWRAPPER_SCRIPT=/usr/local/bin/virtualenvwrapper.sh
export VIRTUALENVWRAPPER_PYTHON=/Library/Frameworks/Python.framework/Versions/3.5/bin/python3
source /usr/local/bin/virtualenvwrapper_lazy.sh
virtualenvwrapper understands the VIRTUALENVWRAPPER_VIRTUALENV environment variable, you need to set it to the virtualenv appropriate to the python version you're using. For example:
export VIRTUALENVWRAPPER_VIRTUALENV=virtualenv3
This is needed because virtualenvwrapper executes virtualenv as a shell script (without adding python2 or python3 in the front of the command).
This way the virtualenv script is executed with the interpreter defined in its shebang (#!).
Most Linux distros provide two packages: virtualenv2 and virtualenv3 each containing one script:
virtualenv2:
#!/usr/bin/python2
import virtualenv
virtualenv.main()
virtualenv3:
#!/usr/bin/python3
import virtualenv
virtualenv.main()
On a Mac you use brew for the python installation. Therefore there is nothing wrong with copying the virtualenv script into two instances: vritualenv2 and virtualenv3 and change the shebang to the correct python version.
(You need to install the virtualenv eggs, through pip, for each python version.)
I defined an alias in the .bashrc file to overwrite the mkproject command to use python3 by default:
alias mkproject='mkproject --python=/usr/bin/python3'
I'm creating a Django app that requires me to use python2.7.6 . My system has python3.4.1 installed so I have to use a virtualenv with python2.7 installed. I installed such a virtualenv using Pycharm and named it django_python_2.7 but when I activate it in the terminal and run "python", it still shows that it's using system's python3.4.1:
here is what I did:
Activate the environment:
source django_python_2.7/bin/activate
Run python, and it shows:
Python 3.4.1 (v3.4.1:c0e311e010fc, May 18 2014, 00:54:21) ---> this is the system level python and not the one installed in virtualenv
However, when I run which python, it shows the correct path that points to virtualenv's python version:
/Users/calvinmwhu/....../django_python_2.7/bin/python
When I explicitly run the python version installed in that virtualenv:
django_python_2.7/bin/python
it shows the correct version:
Python 2.7.6 (default, Sep 9 2014, 15:04:36)
I have no idea what's going on. I'm developing this app in Pycharm IDE but I really like executing commands in the terminal . But in the terminal the virtualenv is not using the correct version of python..Why does running a simple "python" command in the virtualenv still default to the system's python ?
Could anyone provide some hints? Is it necessary to change the PATH variable to make it contain the path to the virtualenv's python?
If you want to change the PYTHONPATH used in a virtualenv, you can add the following line to your virtualenv's django_python_2.7/bin/activate file
export PYTHONPATH="/path/to/python"
export OLD_PYTHONPATH="$PYTHONPATH"
To restore to its original value on deactivate, you could add following line to your django_python_2.7/bin/postdeactivate script.
export PYTHONPATH="$OLD_PYTHONPATH"
Otherwise, create new env using
virtualenv -p /usr/bin/python2.7 django_python_2.7
I discovered the same problem...
and like #skyline75489 mentioned:
I forgot that i had stated an alias to my python3 executable a time ago.
I found it in my .bash files in my home directory and removed it.
Everything worked out fine again with my virtual environment.
If you changed the path to your venv or ranamed any of the parents folders of your venv directory, then this will break the configured paths, if that is case you have two options:
recreating it
Create a requirements.txt file using: pip freeze > requirements.txt
Delete the venv directory: rm -r old-vnev/
Create a new virtualenv with correct name: python -m venv new-venv
Activate new virtualenv: source new-venv/bin/activate
Install packages from requirements.txt: pip install -r requirements.txt
Another simpler way
search for all occurences of the string old/path/to/your/venv/
replace them with correct/path/to/your/venv/
after that source new-venv/bin/activate will work as intended again.
Hope this help!
In case it helps anyone else: if you changed the path to your venv folder (such as changing the parent folder), this will happen. This was my issue.
Recreating your virtualenv will fix it, as you should hopefully have a requirements.txt created to rebuild your virtualenv.
This might have even been the root cause for OP.
Double check your paths. I had an issue like this recently where running which python from within the activated virtualenv would still return the default system version (/usr/bin/python). However, if I ran the scripts specifying the binaries directly (./venv/bin/python, etc) from within the virtualenv, it worked as expected so it appeared all the dependencies had been installed correctly.
The issue was that I had moved the parent virtualenv directory after building everything. This meant all the virtualenv paths pointed to the original location which was no longer valid, and python correctly defaulted to the default system binary.
I use a bash script like this:
$ source venv/bin/activate
$ alias vpython=$VIRTUAL_ENV/bin/python3
and use vpython when wanting to use the python executable within the virtual environment. A nice way to check which executable you are actually using within python is the following:
>>> import sys
>>> print(f'executable \033[0;33;40m{sys.executable}\033[0m')
In my situation after system update symbolic link from the virtualenv was somehow broken and it switched to default system python version. The solution was to replace symbolic link by the correct one.
Deactivate virtual env if you are inside by:
deactivate
Change virtualenv python symbolic link:
ln -s /your/wanted/python/bin/python /your/virtualenv/bin/python
Start virtualenv again and it should use correct python version.
If you are not sure where is your python, then you can localise it by:
which python3
I had a similar problem. But I had it because I had moved my env folder to another place. So, if you did so, just go to activate file in bin folder and change VIRTUAL_ENV="CurrentPathToYourEnvFolder" (it's 40th line in file)
everytime I want to do something with terminal I have to type this sequence in the terminal (Im on mac osx lion terminal):
>Public/projects/installs # location of my venv
>. venv/bin/activate # activates the venv within terminal
Is their anyway to do this faster or create a custom function/ command in the terminal?
There is virtualenvwrapper.
It allows you to switch virtualenvs by typing workon <env_name>. You create virtualenvs by mkvirtualenv <env_name> or mkproject <project_name> if you have set up a PROJECT_HOME and want the working directory there.
You can do a lot more than just switch venvs, though. For example you can set up hooks that are performed for every new venv (installing ipython if you want to, set up a .hgignore) and when activating one (e.g. setting the PATH if you have things installed via npm).
In addition to virtualenvwrapper (already described in two other answers), you might want to check out autoenv. That lets you get into a venv just by doing a cd to its directory.
For fancy stuff, there are a lot of differences between the two projects, and I think virtualenvwrapper is generally more powerful and flexible. But for simple use cases like yours, the choice comes down to which of these you'd prefer:
$ workon projects_installs
… or
$ cd Public/projects/installs
Checkout virtualenvwrapper.
It can be installed with pip install virtualenvwrapper, and requires setting up some lines in your .bashrc file. Then you get the mkproject and workon commands to make creating and switching virtualenvs much easier.