CODEWITHSUNDEEP
pythonlinuxvirtualenvvirtualenvwrapper
liamhawkins
liamhawkins

Reputation: 1371

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

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

Upvotes: 43

Views: 36851

Answers (9)

Rob Reid
Rob Reid

Reputation: 21

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.

Upvotes: 0

Joe
Joe

Reputation: 36

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.

Upvotes: 1

Dylan Tomberlin
Dylan Tomberlin

Reputation: 1

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.

Upvotes: 0

JFK
JFK

Reputation: 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

Upvotes: 0

Evg
Evg

Reputation: 98

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.

Upvotes: 0

vishes_shell
vishes_shell

Reputation: 23484

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.

Upvotes: 59

Gaoping
Gaoping

Reputation: 289

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.

Upvotes: 2

tdelaney
tdelaney

Reputation: 77337

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.

Upvotes: 9

liamhawkins
liamhawkins

Reputation: 1371

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.

Upvotes: 15

Related Questions