Virtualenv uses wrong python, even though it is first in $PATH

Question

I had a problem where python was not finding modules installed by pip while in the virtualenv.

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

When I use which python in the virtualenv I get:

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

When I look up my $PATH variable in the 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 to 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 have not touched /home/liam/dev/.virtualenvs/noots/bin/ in anyway. python and python3.5 are still both linked to python3 in that directory. Traversing to /home/liam/dev/.virtualenvs/noots/bin/ and running ./python, ./python3 or ./python3.5 all work normally.

I am using virtualenvwrapper if that makes a difference, however the problem seemed to occur recently, long after install virtualenv and virtualenvwrapper

• tdelaney: Run alias on the command line to see if python has been aliased.
• liamhawkins: AH thank you! this was the problem.
• oliversm: Please post the solution, as this is an interesting Q.
• Dunes: Don't use which, it doesn't use the same lookup rules as the shell. Use type instead. eg. type python. type will lookup aliases, functions and commands on PATH. which just looks at what's on PATH.

Answer 1

My problem was that i recently moved my project with virtualenv to another location, due to this activate script had 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, just update VIRTUAL_ENV in activate script.

Also you maybe need to fix first line of your bin/pip to link to real python path.

• shaahiin: I had renamed my project folder name and faced the same issue.
• itachi: I can relate. That actually helped me.
• Joachim: If I may add a point, what you need to specify at VIRTUAL_ENV is the path to your virtual environment, and not where python is located
• felixmp: Thank you! Looked everywhere. Hard to put this problem in words. So simple
• Sergey Grechin: that worked for me, though i don't remember moving anything around.

Answer 2

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

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

Answer 3

If you don't get the program that which says you should get, you need to look higher up the chain than the platform executor. Shells typically have a way to alias commands and on most unixy shells you can just enter alias to see which commands have been remapped. Then its just a matter of going to the config files for your shell and removing the alias.

Sometimes people alias python to try to sort out which python they should be using. But there are usually other, better ways. On my linux machine, for example, python3 is in the path but is a symlink to the real python 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 nice because non-shell programs running python get the same one I do and virtual environments work naturally.

• Adam Jagosz: I don't see an example use of alias in your answer. You talk about one thing then show examples of another which is confusing, is all. Sorry if I failed to communicate what I meant right away.
• tdelaney: @AdamJagosz - I am advising against aliasing python so there isn't a need to show how to do it. I showed an example of how linux debs and rpms usually handle the problem of aliasing using symlinks instead.
• Jason Capriotti: @AdamJagosz in case this helps, aliases are commonly set up in your ~/.bashrc or similar file (depending on your shell). I'm not sure if Python installers put aliases there, but in my case I put one there by mistake.

Answer 4

On Cygwin, I still have a problem even after I created 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 a solution. Instead of using virtualenv env, you have to use virtualenv -p F:\Python27\python.exe env even though you have created a symlink.

Answer 5

A reason for this could also be wrong file permissions. For example if the environment had been restored from a backup with the wrong permissions, like it was in my case. Without executable rights in your own environment, it falls back to the default path. After changing permissions with

chmod -R 755 py3Env/

the correct python executable in my environment was chosen again.

Answer 6

I'm currently having the same problem. Virtualenv was created in Windows, now I'm trying to run it from WSL. In virtualenv I renamed python.exe to python3.exe(as I have only python3 command in WSL). In $PATH my virtualenv folder is first, there is no alias for python. I receive which python3 /usr/bin/python3. In /usr/bin/python3 there is symlink `python3 -> python3.6. I suppose it doesn't matter for order resolution.

Answer 7

Had the exact same problem. I ran:

virtualenv -p /venv/bin/python3 env

and got a permission denied. so i tried:

sudo chmod 777 -R /venv/bin

Answer 8

which python and print(sys.executable) were not agreeing for me. This meant that with an active virtualenv pip install <package> would install to the virtualenv, but running python would be the base install.

I eventually got around this by running

virtualenv -p \path\to\python.exe --always-copy <venvName>

I'm not sure if specifying the path to the original python is really necessary, but can't hurt. According to the man page:

 --copies, --always-copy try to use copies rather than symlinks, even when symlinks are the default for the platform (default: False)

I'm using windows powershell with msys64.

Answer 9

I just realized that my shell's SPARK_HOME and SPARK_PATH were causing this problem even though the correct venv entry had been added to my PATH. Everything started working once I removed SPARK_HOME and SPARK_PATH from my shell.