Virtualenv uses the wrong python, although it is the first in $ PATH

Question

I had a problem when python could not find the modules installed by the peak, while in virtualenv.

I narrowed it down and found that when I call python , when my virtualenv is activated, it still reaches /usr/bin/python instead of /home/liam/dev/.virtualenvs/noots/bin/python .

When I use which python in virtualenv, I get:

/home/liam/dev/.virtualenvs/noots/bin/python

When I look at my $PATH variable in virtualenv, I get:

bash: /home/liam/dev/.virtualenvs/noots/bin:/home/liam/bin:/home/liam/.local/bin:/home/liam/bin:/home/liam/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin: No such file or directory

and yet, when I actually run python , it goes to /usr/bin/python

To make things more confusing for me, if I run python3.5 , it grabs python3.5 from the correct directory (i.e. /home/liam/dev/.virtualenvs/noots/bin/python3.5 )

I did not touch /home/liam/dev/.virtualenvs/noots/bin/ at all. python and python3.5 are still linked to python3 in this directory. Going to /home/liam/dev/.virtualenvs/noots/bin/ and starting ./python , ./python3 or ./python3.5 work fine.

I use virtualenvwrapper if that matters, however the problem seems to have occurred recently, long after installing virtualenv and virtualenvwrapper

Answer 1

If you don’t get a program which which says you should get it, you need to look up the chain than the platform executor. Typically, a shell has a way for aliases, and in most unixy shells you can simply enter alias to see which commands have been reassigned. Then it’s just a matter of going to the configuration files for your shell and removing the alias.

Sometimes alias python people try to sort which python they should use. But usually there are other, better ways. For example, on my linux machine, python3 is on the way, but is a symbolic link to the real python that I am using.

 td@mintyfresh ~ $ which python3 /usr/bin/python3 td@mintyfresh ~ $ ls -l /usr/bin/python3 lrwxrwxrwx 1 root root 9 Feb 17 2016 /usr/bin/python3 -> python3.4 td@mintyfresh ~ $ 

This is good, because the shellless programs running python get the same thing as I do, and virtual environments work naturally.

Answer 2

My problem was that I recently moved my project from virtualenv to another location because this activate script had the wrong VIRTUAL_ENV path.

 $ cat path_to_your_env/bin/activate ... # some declarations VIRTUAL_ENV="/path_to_your_env/bin/python" # <-- THIS LINE export VIRTUAL_ENV ... # some declarations 

To fix this, simply update VIRTUAL_ENV in the activate script.

You may also need to fix the first line of your bin/pip to reference the actual Python path.

Answer 3

Like the tdelaney suggested in the comments, I ran alias and found that I previously had the python alias before /usr/bin/python3.5 in my .bashrc .

I removed this alias from my .bashrc , ran unalias python and source ~/.bashrc , and the problem was resolved.

Answer 4

On Cygwin, I still have a problem even after I created a symlink to point /usr/bin/python to F:\Python27\python.exe . Here, after source env/Scripts/activate , which python is still /usr/bin/python .

After a long time, I figured out the solution. Instead of using virtualenv env , you should use virtualenv -p F:\Python27\python.exe env even if you created a symbolic link.

Answer 5

I have the same problem now. Virtualenv was created on Windows, now I'm trying to run it from WSL. In virtualenv, I renamed python.exe to python3.exe (since I only have the python3 command in WSL). In $ PATH, my virtualenv folder is the first, there is no alias for python. I get which python3 /usr/bin/python3 . In /usr/bin/python3 there is a symbolic link 'python3 -> python3.6. I suppose it doesn’t matter for order authorization.