Virtualenv doesn't use right version of Python

Question

I'm working in Amazon's Cloud9.

ec2-user:~/environment/flask_init $ python -V
Python 2.7.14
ec2-user:~/environment/flask_init $ virtualenv -p python3 venv
Running virtualenv with interpreter /usr/bin/python3
Using base prefix '/usr'
New python executable in /home/ec2-user/environment/flask_init/venv/bin/python3
Also creating executable in /home/ec2-user/environment/flask_init/venv/bin/python
Installing setuptools, pip, wheel...done.
ec2-user:~/environment/flask_init $ source venv/bin/activate
(venv) ec2-user:~/environment/flask_init $ python -V
Python 2.7.14

Why is the virtual environment not using Python 3?

Please note that this question is not a duplicate of this one. The issue was specifically to do with the way the Cloud 9 environment sets up Python alias.

Anglocatholic

could you try giving the full path to python3 while creating virtualenv like virtualenv -p path/to/python3 venv – Clavius

Still doesn't work when I create using the link /usr/bin/python3 – Anglocatholic

@Anglocatholic Could you please try creating the venv again with -v flag and paste the logs into the question? – Ophite

Everything looks okay in your output, could you try executing python3 -v and if the output is Python 3.x then try running python3 -m virtualenv venv – Clavius

@Ophite Stack Overflow says there's too much code in the edit when I enter the logs, so I pasted it here: (pastebin.com/dSzuM73a) – Anglocatholic

@Anglocatholic Do you have a shell alias named python? Can you try commands: which python; $(which python) --version? – Coactive

Possible duplicate of Use different Python version with virtualenv – Floatation

Answer 1

I tried your flow on my machine and everything works as expected.

dluzak@Karol-PC:/tmp$ python -V
Python 2.7.12
dluzak@Karol-PC:/tmp$ virtualenv -p python3 venv
Already using interpreter /usr/bin/python3
Using base prefix '/usr'
New python executable in /tmp/venv/bin/python3
Also creating executable in /tmp/venv/bin/python
Installing setuptools, pkg_resources, pip, wheel...done.
dluzak@Karol-PC:/tmp$ source venv/bin/activate
(venv) dluzak@Karol-PC:/tmp$ python -V
Python 3.5.2
(venv) dluzak@Karol-PC:/tmp$ 

Nonetheless I personally use virtualenv as module when creating venv with python 3: python3 -m virtualenv venv. Maybe this would work.

You provided very little details. Have you installed virtualenv for both Python 2 and 3? Are you sure Python 3 interpreter works fine?

Edit:

After investigation in comments we found out that the problem was in bash settings configured by Amazon. It seams that Amazon configures bash (probably in ~/.bashrc) to replace python calls with an alias. To fix this a call unalias python before enabling venv is needed. It is described in Amazon docs

Ophite

thanks for the suggestions. Python 3 interpreter runs and shows v3.6.5. python3 -m pip install virtualenv gives me Requirement already satisfied: virtualenv in /usr/local/lib/python3.6/site-packages. I tried your module approach but the virtual environment is still running Python 2. – Anglocatholic

It's almost as though the virtual environment isn't running, because when I am in it and run python3 it opens the python3 interpreter. So it seems to have two pythons and is using python3 by default, just like the host environment without the virtual environment running. – Anglocatholic

@Anglocatholic I don't quite understand your second comment. So after activating virtualenv, when calling python3 you are getting python3, that is: exactly what you wanted? If in doubt if it is the host or virtualenv one you can call which python3 – Ophite

Python3 is definitely the virtual environment's version: ~/environment/flask_init/venv/bin/python3 - but I want this virtual environment to use python 3 by default, and right now it's using python 2.7 by default. I didn't want Python 2 at all in this venv. – Anglocatholic

@Anglocatholic venv/bin/python should be symlink pointing to the venv/bin/python3. Could you check if thats the case? The easiest way would be to call ls -alF ~/environment/flask_init/venv/bin. – Ophite

@Anglocatholic You can also check if after activating the venv the PATH has the ~/environment/flask_init/venv/bin directory as the first element with echo $PATH – Ophite

Thanks @Dluzak. I ran that and here are the results. (pastebin.com/31Jx2iwM). It seems to be pointing to python 3 binaries, right? – Anglocatholic

Yup, that directory is first in the $PATH. But how do I get the virtual environment to use Python3 by default? – Anglocatholic

@Anglocatholic Have you tried which python after activating the venv? – Ophite

@Dluzac alias python='python27' /usr/bin/python27. I wonder if this is just something to do with how Amazon has Cloud9 set up. I've had no problems with virtualenv on local machines in the past. – Anglocatholic

Ok, now it makes sense. The problem is in your bash settings. It seams that Amazon configured your bash (probably in ~/.bashrc) to replace python calls with this alias. If you call unalias python before enabling venv, everything should work. It is even included in Amazon docs – Ophite

Nailed it! Thanks so much, @Dluzak. – Anglocatholic

Answer 2

When I was using virtualenv earlier today, I had the same problem that my env was not using the right version of python.

Instead of activating my environment like this:

source activate

I found that activating it like this actually worked:

source ./activate

Hope this is helpful!

Herminahermine

Answer 3

Here is how i create virtualenv on Cloud9

Python 3.4

$ sudo pip install virtualenv
$ virtualenv -p /usr/bin/python3.4 venv
$ source venv/bin/activate

Python 3.6

$ sudo apt update
$ sudo apt install python3.6-venv
$ python3.6 -mvenv venv
$ source venv/bin/activate

Sybille

Answer 4

I have encountered a similar issue. In my case did not work because I moved the virtual env folder (but the same thing happens when you rename it).

You can understand which version of python (and thus which module will import) is using by typing

$ which python

If it write something like:

/usr/bin/python

Then it means your virtual env is not being activated.
To solve this issue, instead of creating a new virtual environment, you can simply edit the script activation file in your env:

$ nano venv/bin/activate

And edit the following line with your absolute path of your virtual environment:

VIRTUAL_ENV="/YOUR_ABSOLUT/PATH_TO/venv"

Hope it helps :)

Uhf