I\'ve got various versions of python installed on my Mac using Macports. When I\'ve selected python 2.7 via $ port select python python27
, virtualenvwrapper works p
You can select the python version explicitly
mkvirtualenv -p python3 venvname
or
mkvirtualenv -p python2.7 venvname
I know this is pretty much solved in your comments, but it's mac only,
and even more I think the correct way should be to set VIRTUALENVWRAPPER_PYTHON
to the real python you are using on the command line.
To be sure you can do which python
.
Actually, you can even do:
export VIRTUALENVWRAPPER_PYTHON=`which python`
On linux I do this in my .bashrc, so all in all, assuming you installed virtualenv and created your first "virtual environment" virtualenv
(how original)
. virtualenv/bin/activate
export WORKON_HOME=$HOME/.virtualenvs # or whatever else you want
export VIRTUALENVWRAPPER_PYTHON=`which python`
export PROJECT_HOME=SOMETHING
source $HOME/virtualenv/bin/virtualenvwrapper.sh # or wherever else you got that installed
(and by the way, you wrote:
I checked my .profile and it's setting VIRTUALENVWRAPPER_PYTHON to /opt/local/bin/python, so it seems to me virtualenvwrapper should work regardless of which python I've selected
which is actually the opposite - virtualenv relies on using the correct python (and the packages that go with it) so it's very important to set the python path accordingly.
Even running a py file with a "#!/bin/python" might bring trouble once you are virtualenved!
You (the OP) seem to have installed virtualenv and virtualenvwrapper with python2.7, and not with python2.6. If python2.6 is called at the moment your shell loads the virtualenvwrapper.sh script, it is unhappy. Pretty straightforward.
VIRTUALENVWRAPPER_PYTHON
is made for those situations. With it, you can make sure you always use the right version of python, and don't have to always add that -p /path/to/python2.7
So, I don't agree with Stefano's answer in that case, in the OP's situation, you should have explained clearly in your .bashrc which python to use:
...
export VIRTUALENVWRAPPER_PYTHON=/path/to/your/python2.7
source /path/to/bin/virtualenvwrapper.sh
Like that it should be ok all the time! Virtualenvwrapper is done to simplify things.
Also, please note that /opt/local/bin/python
must be a symlink to the version of python you select with port python select
(check that with ls -l /opt/local/bin/python
to be sure).
Confirmed the use of two similarly-named environment variables:
VIRTUALENVWRAPPER_PYTHON
-- which Python version is used by the virtualenvwrapper utility itself. In other words, which version of Python executes virtualenvwrapper
, as if that Python version had been explicitly named in the #!
line of the virtualenvwrapper script file.
VIRTUALENV_PYTHON
-- which Python version will be installed by virtualenv
when you create a new virtual environment. Equivalent to -p / --python
option on the virtualenv
command line.
And perhaps obviously :) the version of Python run in a virtual environment is the version you install for that environment -- has no relation to the above environment variables after the env is created.
See https://stackoverflow.com/a/24724360/763269 for how to upgrade Python within a virtualenv.
None of these worked. I installed Python3 first when setting up my osx machine, and pip and all default to that.
First, check which python you have installed:
$ `which python` -V
If this returns "Python 2.7.12", then you are set to run:
$ mkvirtualenv -p `which python` api_server
Running virtualenv with interpreter /usr/local/bin/python
New python executable in /Users/eric/.virtualenvs/api_server/bin/python2.7
Also creating executable in /Users/eric/.virtualenvs/api_server/bin/python
Installing setuptools, pip, wheel...done.
virtualenvwrapper.user_scripts creating /Users/eric/.virtualenvs/api_server/bin/predeactivate
virtualenvwrapper.user_scripts creating /Users/eric/.virtualenvs/api_server/bin/postdeactivate
virtualenvwrapper.user_scripts creating /Users/eric/.virtualenvs/api_server/bin/preactivate
virtualenvwrapper.user_scripts creating /Users/eric/.virtualenvs/api_server/bin/postactivate
virtualenvwrapper.user_scripts creating /Users/eric/.virtualenvs/api_server/bin/get_env_details
This will also activate the api_server
workon, which changes your python executable:
$ which python
/Users/eric/.virtualenvs/api_server/bin/python
$ python -V
Python 2.7.12
What does which python
actually do? It outputs the directory of the python executables found in your PATH:
$ which python
/usr/local/bin/python
By using which python
, you are basically passing in /usr/local/bin/python
to the -p
option in the mkvirtualenv directory.
What happens when you have more than one python executable returned in which python
? Just find the one you want and pass it in:
$ mkvirtualenv -p /usr/local/bin/python3 api_server
And virtualenvwrapper will end up using that python executable instead.