No module named 'virtualenvwrapper'
Instead of specifying a different python interpreter with -p
flag, you can also config your desired interpreter as default.
According to virtualenvwrapper
's documentation, virtualenvwrapper.sh
finds the first python
and virtualenv
programs on the $PATH
and remembers them to use later.
If your virtualenvwrapper
is not installed on your OS's default python interpreter (/usr/bin/python
), make sure you override the environment variables as below:
VIRTUALENVWRAPPER_PYTHON
to the full path of your python interpreterVIRTUALENVWRAPPER_VIRTUALENV
to the full path of the virtualenv
For example, on my .bash_profile
(Mac):
#virtualenvwrapperexport WORKON_HOME=$HOME/.virtualenvsexport VIRTUALENVWRAPPER_PYTHON=/Library/Frameworks/Python.framework/Versions/3.5/bin/python3export VIRTUALENVWRAPPER_VIRTUALENV=/Library/Frameworks/Python.framework/Versions/3.5/bin/virtualenvsource /Library/Frameworks/Python.framework/Versions/3.5/bin/virtualenvwrapper.sh
Reload your new variables by running source ~/.bash_profile
I had the same problem after the recent Homebrew updates.
In the past, most people would have run pip install virtualenvwrapper
into the system site packages and it would have worked.
Homebrew broke this workflow by 1) no longer shadowing the system python, and 2) no longer symlinking pip to pip2/pip3
.
Most users will realize this when they can't find pip
, and then try to use pip2/pip3
. However, using pip2/pip3
will create a problem because virtualenvwrapper
is now installed for python2/python3
, but not for python
. So when virtualenvwrapper
runs and calls python, it won't find the virtualenvwrapper/virtualenv
python packages in the system python's site packages.
Explicitly setting VIRTUALENVWRAPPER_PYTHON
is the cleanest fix, and not a hack. Here's how I did it in my dotfiles
export VIRTUALENVWRAPPER_PYTHON=/usr/local/bin/python3
On Ubuntu 20.04, the problem can occur when trying to install virtualenvwrapper with python 3.8 (python 3 default) and init the wrapper with python 2.7 (python 2 default).
TL;DR
Manually set python3 interpreter
export VIRTUALENVWRAPPER_PYTHON=$(which python3)source /usr/local/bin/virtualenvwrapper.sh
In more details, Why does this happen?
Let's get some informations:
$ which python/usr/bin/python$ python --versionPython 2.7.18rc1$ which python3/usr/bin/python3$ python3 --versionPython 3.8.2$ pip3 --versionpip 20.0.2 from /usr/lib/python3/dist-packages/pip (python 3.8)
Following the guidelines, we are asked to install virtualenvwrapper with pip (python 3):pip3 install virtualenvwrapper
Current stable version (4.8.4) of virtualenvwrapper is linking to default python
version, which we saw it's python 2.7:
VIRTUALENVWRAPPER_PYTHON="$(command \which python)"
So, the problem is that we installed virtualenvwrapper in python3 and try to init with python2 (sourcing shell script). The fix is therefore to init with python 3 by overriding default.
But, it is very likely that one of the next releases will include a fix already merged onto master that look from highest to lowest python version:
if [ "${VIRTUALENVWRAPPER_PYTHON:-}" = "" ]then for NAME in python3 python2 python do python_executable="$(which $NAME 2>/dev/null)" if ! [ -z "$python_executable" ] then if $python_executable -m 'virtualenvwrapper.hook_loader' --help >/dev/null 2>&1 then VIRTUALENVWRAPPER_PYTHON=$python_executable break fi fi done
Using in the documentation, the fix is to manually set the Python interpreter to use before sourcing: Not python (2.7) but python3 (3.8 here)
export VIRTUALENVWRAPPER_PYTHON=$(which python3)source /usr/local/bin/virtualenvwrapper.sh