Develop Reference

python virtualenv does not use correct version of python

I'm creating a Django app that requires me to use python2.7.6 . My system has python3.4.1 installed so I have to use a virtualenv with python2.7 installed. I installed such a virtualenv using Pycharm and named it django_python_2.7 but when I activate it in the terminal and run "python", it still shows that it's using system's python3.4.1:
here is what I did:
Activate the environment:
source django_python_2.7/bin/activate
Run python, and it shows:
Python 3.4.1 (v3.4.1:c0e311e010fc, May 18 2014, 00:54:21) ---> this is the system level python and not the one installed in virtualenv
However, when I run which python, it shows the correct path that points to virtualenv's python version:
/Users/calvinmwhu/....../django_python_2.7/bin/python
When I explicitly run the python version installed in that virtualenv:
django_python_2.7/bin/python
it shows the correct version:
Python 2.7.6 (default, Sep 9 2014, 15:04:36)
I have no idea what's going on. I'm developing this app in Pycharm IDE but I really like executing commands in the terminal . But in the terminal the virtualenv is not using the correct version of python..Why does running a simple "python" command in the virtualenv still default to the system's python ?
Could anyone provide some hints? Is it necessary to change the PATH variable to make it contain the path to the virtualenv's python?

If you want to change the PYTHONPATH used in a virtualenv, you can add the following line to your virtualenv's django_python_2.7/bin/activate file
export PYTHONPATH="/path/to/python"
export OLD_PYTHONPATH="$PYTHONPATH"
To restore to its original value on deactivate, you could add following line to your django_python_2.7/bin/postdeactivate script.
export PYTHONPATH="$OLD_PYTHONPATH"
Otherwise, create new env using
virtualenv -p /usr/bin/python2.7 django_python_2.7

I discovered the same problem...
and like #skyline75489 mentioned:
I forgot that i had stated an alias to my python3 executable a time ago.
I found it in my .bash files in my home directory and removed it.
Everything worked out fine again with my virtual environment.

If you changed the path to your venv or ranamed any of the parents folders of your venv directory, then this will break the configured paths, if that is case you have two options:
recreating it
Create a requirements.txt file using: pip freeze > requirements.txt
Delete the venv directory: rm -r old-vnev/
Create a new virtualenv with correct name: python -m venv new-venv
Activate new virtualenv: source new-venv/bin/activate
Install packages from requirements.txt: pip install -r requirements.txt
Another simpler way
search for all occurences of the string old/path/to/your/venv/
replace them with correct/path/to/your/venv/
after that source new-venv/bin/activate will work as intended again.
Hope this help!

In case it helps anyone else: if you changed the path to your venv folder (such as changing the parent folder), this will happen. This was my issue.
Recreating your virtualenv will fix it, as you should hopefully have a requirements.txt created to rebuild your virtualenv.
This might have even been the root cause for OP.

Double check your paths. I had an issue like this recently where running which python from within the activated virtualenv would still return the default system version (/usr/bin/python). However, if I ran the scripts specifying the binaries directly (./venv/bin/python, etc) from within the virtualenv, it worked as expected so it appeared all the dependencies had been installed correctly.
The issue was that I had moved the parent virtualenv directory after building everything. This meant all the virtualenv paths pointed to the original location which was no longer valid, and python correctly defaulted to the default system binary.

I use a bash script like this:
$ source venv/bin/activate
$ alias vpython=$VIRTUAL_ENV/bin/python3
and use vpython when wanting to use the python executable within the virtual environment. A nice way to check which executable you are actually using within python is the following:
>>> import sys
>>> print(f'executable \033[0;33;40m{sys.executable}\033[0m')

In my situation after system update symbolic link from the virtualenv was somehow broken and it switched to default system python version. The solution was to replace symbolic link by the correct one.
Deactivate virtual env if you are inside by:
deactivate
Change virtualenv python symbolic link:
ln -s /your/wanted/python/bin/python /your/virtualenv/bin/python
Start virtualenv again and it should use correct python version.
If you are not sure where is your python, then you can localise it by:
which python3

I had a similar problem. But I had it because I had moved my env folder to another place. So, if you did so, just go to activate file in bin folder and change VIRTUAL_ENV="CurrentPathToYourEnvFolder" (it's 40th line in file)

How to install python modules in a local directory? --user and exporting pythonpath isn't working

I don't know very much about python but would like to install some python modules in a local directory on a server on which I don't have sudo access.
I start by going into my desired directory (not root) and create the directory tree needed to store my custom modules
cd /root/example/sub-example
mkdir -p local/lib/python2.7/site-packages
I then export this local path to PYTHONPATH
export PYTHONPATH=$PYTHONPATH:/root/example/sub-example/local/lib/python2.7/site-packages
I then make a new sub-directory to store the python package while extracting
mkdir example-python-directory
cd example-python-directory
wget http://example-python-package
tar -xvf example-python-package.tar.gz
cd example-python-package
Last, I run the setup.py script with the --user flag to try to get it to install in my specified /local directory
python setup.py install --user
The problem is, nothing is installed in my /root/example/sub-example/local/lib/python2.7/site-packages directory, and instead I find that I now have a new directory at root: /root/.local/lib/python2.7/site-packages
Is there a way to prevent this? I feel like my lack of Python knowledge is causing me to make some silly error that is probably obvious to others. Thanks for the help!

create a folder called "lib"
For Python 3
pip3 install <your_python_module_name> -t lib/
For Python 2
pip install <your_python_module_name> -t lib/

CFLAGS=-I$(brew --prefix)/include LDFLAGS=-L$(brew --prefix)/lib pip install <package>
I found that on servers where you haven't root access to, you can usually install the python module into your .brew/lib using this.

virtualenv is what I would recommend for this case (and pretty much any other case). I use it for pretty much everything I do in Python.
It allows you to essentially create a sandbox containing a Python environment that is bootstrapped from a Python install on your machine, and to install any modules you want into it.
It should not, in general, require the use of sudo, since you're not touching the system install. You can generally pip install a module right into the virtualenv, and then you run your scripts out of that virtualenv. You would basically just need a location you can read/write/execute from, say a directory you create in your user's home directory.
You can keep track of what's installed by doing a pip freeze > requirements and checking that into an SCM, and then a new virtualenv can be recreated using that file, ready to run your scripts.
The link I provided above has more details about how to use virtualenv.
Edit in response to comment from OP:
You can still use pip install outside of virtualenv, and I would recommend that. However, that can only operate on various Python installs that may be on the box (invoke pip from the bin directory of the install you want to use).
However, that won't work for installation into arbitrary directories. For that, you could try to unzip the egg file (they are supposed to be zip files) into the directory you want, and then make sure that directory is on the PYTHONPATH. Some egg files are available for direct download off of PyPI, although some are source only.
I think is approach is much more complex and prone to problems than virtualenv would be, though.

Python OSX $ which Python gives /Library/Frameworks/Python.framework/Versions/2.7/bin/python

Hello I'm trying to run twisted along with python but python cannot find twisted.
I did run $pip install twisted successfully but it is still not available.
ImportError: No module named twisted.internet.protocol
It seems that most people have $which python at /usr/local/bin/python
but I get /Library/Frameworks/Python.framework/Versions/2.7/bin/python
May this be the issue? If so, how can I change the PATH env?

It is just fine.
Python may be installed in multiple places in your computer.
When you get a new Mac, the default python directory may be
'usr/bin/python2.7'
You may also have a directory
'System/Library/Frameworks/Python.framework/Versions/2.7/bin/python'
The first one is the symlink of the second one.
If you use HomeBrew to install python, you may get a directory in
'usr/local/bin/python2.7'
You may also have a directory as
'Library/Frameworks/Python.framework/Versions/2.7/bin/python'
which is exactly where my directory is.
The difference between the second one and the fourth one, you may find it here
Installing Your Framework
In your question, as you mentioned pip install is successful, but the installed packages still not available. I may guess your pip directory is not in your default python directory, and the packages are installed where your pip directory is. (Please use 'which pip' to check it out)
For example, in my computer, the default pip directory is
/Library/Frameworks/Python.framework/Versions/2.7/bin/pip
though, I have also pip in usr/local/bin.
So, all my packages installed via 'pip install' are stored in
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages
Hope that resolves your doubt. Similar things have happened to me, and it took me a whole night to figure out.
Here is the solution:
Use PYTHONPATH="/usr/local/lib/python2.7/site-packages:$PYTHONPATH" to modify your python directory, or modify your pip directory.
However, I would recommend a better way, use virtualenv. This can isolates Python environments, and can help you easily set up packages for each project.

By the path your giving for OS X python I'm guessing your a rev-or-so old on your OS X (leopard?) so I can't directly compare with my machine.
But, adding packages to the base OS X install is always a touchy thing, one check I would recommend is the permissions on any packages you add. Do a ls -l /Library/Python/2.7/site-packages/ and make sure everything has r rights (and x rights for directories) (I.E. -rwxr-xr-x or drwxr-xr-x).
I had a recent case where a sudo pip wouldn't set user read rights on installed packages, and I believe "No module" was the error I was getting when I tried to use them
Because adding packages is so touchy on OS X, there are tons of guide on the net to doing hand installs of python. The first one I matched on a google is Installing / Updateing Python on OS X (use at your own risk, I personally haven't followed that guide)
(... the 3rd part install system Brew is a very common method for people to do automated installs of python as well)

Okay well in the terminal I finally found out:
open .bash_profile located at your user root (simply do a $cd in terminal to go there) and add where the path is the location of twisted
PYTHONPATH="/usr/local/lib/python2.7/site-packages:$PYTHONPATH"
export PYTHONPATH

I too was getting a ImportError: No module named xxxeven though I did a pip install xxx and pip2 install xxx.
pip2.7 install xxx worked for me. This installed it in the python 2.7 directory.

Trouble Installing Python with Framework-style Build (OS X)

In attempting to get started learning and developing python, I've tried to follow the Python Guide to installing python on OS X, but haven't found it particularly "noob friendly." I have a new MacBook (Mtn. Lion - OS X 10.8.3) wich comes with Python 2.7.2 built in. But the guide advises installing a "framework-style build" via homebrew. So:
I installed homebrew via ruby -e "$(curl -fsSL https://raw.github.com/mxcl/homebrew/go)"
Then it tells you to add homebrew to the top of your PATH by adding it to your ~/.bashrc file. ls -a showed that I did not have a ~/.bashrc file in my home directory. After searching Stack Overflow on how to do that, I ran nano ~/.bashrc, and inserted the line export PATH=/usr/local/bin:$PATH to the file and saved the file.
I then ran brew install python --framework and the install completed.
Then, the guide says to "add the new Python scripts directory to your PATH" so, I'm assuming that means I need to add the line it provides to my ~/.bashrc file also. So, I added export PATH=/usr/local/share/python:$PATH to my ~/.bashrc file above my previous entry.
Finally, this is where I run into trouble, it says to easy_install pip. However, when I do that I get an error 13.
So, here are the things I need some help with.
Was I correct in my assumptions about how to add homebrew and python scripts to my PATH?
Did I do something wrong or do I just need to use sudo to install pip? (I'm really sorry if the answer is already on this page but even those answers don't make total sense to me and I want to be careful and not screw something up)
After installing the framework-style build of python (which I believe was the current 2.7.3), how come running python in my terminal still shows v2.7.2?
Thanks! I appreciate any help.

I've tried to follow the Python Guide to installing python on OS X,
but haven't found it particularly "noob friendly.
Yes, I think it is misleading/outdated.
Then it tells you to add homebrew to the top of your PATH by adding it
to your ~/.bashrc file. ls -a showed that I did not have a ~/.bashrc
file in my home directory. After searching Stack Overflow on how to do
that, I ran nano ~/.bashrc, and inserted the line export
PATH=/usr/local/bin:$PATH to the file and saved the file.
On the Mac, just use ~/.profile
I then ran brew install python --framework and the install completed.
I think you don't need the --framework option unless you want to replace your Mac OS default installation and need an Mac OS Framework-style directory layout. There is no need to replace it though, the homebrew installation will take precedence anyway.
Then, the guide says to "add the new Python scripts directory to your
PATH" so, I'm assuming that means I need to add the line it provides
to my ~/.bashrc file also. So, I added export
PATH=/usr/local/share/python:$PATH to my ~/.bashrc file above my
previous entry.
Again, do it in ~/.profile. And don't forget to do a
source ~/.profile
otherwise the changes will only become active in any new terminal window, not the one you are currently using.
Finally, this is where I run into trouble, it says to easy_install
pip. However, when I do that I get an error 13.
The error shows that you try to install it your Mac OS system's default Python library (rather than in /usr/local, homebrew style), which would require root privileges. Just don't.
Also, with homebrew python, pip is already installed.
Check your path:
$ which pip
/usr/local/bin/pip
$ ls -l /usr/local/bin/pip
[..] /usr/local/bin/pip -> ../Cellar/python/2.7.3/bin/pip
Added bonus: Then do
pip install virtualenv
and use that.
And to your questions:
Was I correct in my assumptions about how to add homebrew and python
scripts to my PATH?
Yes, but use .profile and do a source .profile afterwards.
Did I do something wrong or do I just need to use sudo to install pip?
(I'm really sorry if the answer is already on this page but even those
answers don't make total sense to me and I want to be careful and not
screw something up)
You don't need sudo with homebrew, and pip is installed automatically with homebrew python.
After installing the framework-style build of python (which I believe
was the current 2.7.3), how come running python in my terminal still
shows v2.7.2?
Probably PATH not correct, do echo $PATH and check that it is correct. That is unrelated to being "framework-style" or not, though.

If you installed python with homebrew, you should already have pip installed. Try running
pip --version
to see whether and where pip is installed. Hopefully it's in a /usr/local/... path where your other homebrew things live.
Also before you install too much more with homebrew be sure to run these commands:
brew update
brew doctor
Good luck!

Problem with virtualenv in Mac OS X

I've installed virtualenv via pip and get this error after creating a new environment:
selenium:~ auser$ virtualenv new
New python executable in new/bin/python
ERROR: The executable new/bin/python is not functioning
ERROR: It thinks sys.prefix is u'/System/Library/Frameworks/Python.framework/ Versions/2.6' (should be '/Users/user/new')
ERROR: virtualenv is not compatible with this system or executable
In my environment:
PYTHONPATH=/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages
PATH=/System/Library/Frameworks/Python.framework/Versions/2.6/bin:/Library/Frameworks/Python.framework/Versions/2.6/bin:/Library/Frameworks/Python.framework/Versions/2.6/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin
How can I repair this?
Thanks.

Just in case there's someone still seeking for the answer.
I ran into this same problem just today and realized since I already have Anaconda installed, I should not have used pip install virtualenv to install virtual environment as this would give me the error message when trying to initiate it later. Instead, I tried conda install virtualenv then entered virtualenv env_mysite and problem solved.

Like #RyanWilcox mentioned, you might be inadvertently pointing virtualenv to the wrong Python installation. Virtualenv comes with a -p flag to let you specify which interpreter to use.
In my case,
virtualenv test_env
threw the same error as yours, while
virtualenv -p python test_env
worked perfectly.
If you call virtualenv -h, the documentation for the -p flag will tell you which python it thinks it should be using; if it looks wonky, try passing -p python. For reference, I'm on virtualenv 1.11.6.

In case anyone in the future runs into this problem - this is caused by your default Python distribution being conda. Conda has it's own virtual env set up process but if you have the conda distribution of python and still wish to use virtualenv here's how:
Find the other python distribution on your machine: ls -ls /usr/bin/python*
Take note of the availble python version that is not conda and run the code below (note for python 3 and above you have to upgrade virtualenv first): virtualenv -p python2.7(or your python version) flaskapp

I've run across this problem myself. I wrote down the instructions in a README, which I have pasted below....
I have found there are two things that work:
Make sure you're running the latest virtualenv (1.5.1, of this writting)
If you're using a non system Python as your standard Python (which python to check) Forcefully use the System supplied one.
Instead of virtualenv thing use /usr/bin/python2.6 PATH/TO/VIRTUALENV thing (or whatever which
python returned to you - this is what it did for me when I ran into this issue)

I had the same problem and as I see it now, it was caused by a messy Python installation. I have OS X installed for over a year since I bought a new laptop and I have already installed and reinstalled Python for several times using different sources (official binaries, homebrew, official binaries + hand-made adjustments as described here). Don't ask me why I did that, I'm just a miserable newbie believing everything will fix itself after being re-installed.
So, I had a number of different Pythons installed here and there as well as many hardlinks pointing at them inconsistently. Eventually I got sick of all of them and reinstalled OS X carefully cleaned the system from all the Pythons I found using find utility. Also, I have unlinked all the links pointing to whatever Python from everywhere. Then I've installed a fresh Python using homebrew, installed virtualenv and everything works as a charm now.
So, my recipe is:
sudo find / -iname "python*" > python.log
Then analyze this file, remove and unlink everything related to the version of Python you need, reinstall it (I did it with homebrew, maybe official installation will also work) and enjoy. Make sure you unlink everything python-related from /usr/bin and /usr/local/bin as well as remove all the instances of Frameworks/Python.framework/Versions/<Your.Version> in /Library and /System/Library.
It may be a dirty hack, but it worked for me. I prefer not to keep any system-wide Python libraries except pip and virtualenv and create virtual environments for all of my projects, so I do not care about removing the important libraries. If you don't want to remove everything, still try to understand whether your Pythons are, what links point to them and from where. Then think what may cause the problem and fix it.

I ran into a variation of this "not functioning" error.
I was trying to create an environment in a folder that included the path ".../Programming/Developing..." which is actually "/Users/eric/Documents/Programming:Developing/"
and got this error:
ImportError: No module named site
ERROR: The executable env/bin/python2.7 is not functioning
ERROR: It thinks sys.prefix is u'/Users/eric/Documents/Programming:Developing/heroku' (should be u'/Users/eric/Documents/Programming:Developing/heroku/env')
ERROR: virtualenv is not compatible with this system or executable
I tried the same in a different folder and it worked fine, no errors and env/bin has what I expect (activate, etc.).

I got the same problem and I found that it happens when you do not specify the python executable name properly. So for python 2x, for example:
virtualenv --system-site-packages -p python mysite
But for python 3.6 you need to specify the executable name like python3.6
virtualenv --system-site-packages -p python3.6 mysite

On on OSX 10.6.8 leopard, after having "upgraded" to Lion, then downgrading again (ouch - AVOID!), I went through the Wolf Paulus method a few months ago, completely ignorant of python. Deleted python 2.7 altogether and "replaced" it with 3.something. My FTP program stopped working (Fetch) and who knows what else relies on Python 2.7. So at that point I downloaded the latest version of 2.7 from python.org and it's installer got me up and running - until i tried to use virtualenv.
What seems to have worked for me this time was totally deleting Python 2.7 with this code:
sudo rm -R /System/Library/Frameworks/Python.framework/Versions/2.7
removing all the links with this code:
sudo rm /usr/bin/pydoc
sudo rm /usr/bin/python
sudo rm /usr/bin/pythonw
sudo rm /usr/bin/python-config
I had tried to install python with homebrew, but apparently it will not work unless all of XTools is installed, which I have been avoiding, since the version of XTools compatible with 10.6 is ancient and 4GB and mostly all I need is GCC, the compiler, which you can get here.
So I just installed with the latest download from python.org.
Then had to reinstall easy_install, pip, virtualenv.
Definitely wondering when it will be time for a new laptop, but there's a lot to be said for buying fewer pieces of hardware (slave labor, unethical mining, etc).

The above solutions failed for me, but the following worked:
python3 -m venv --without-pip <ENVIRONMENT_NAME>
. <ENVIRONMENT_NAME>/bin/activate
curl https://bootstrap.pypa.io/get-pip.py | python
deactivate
It's hacky, but yes, the core problem really did just seem to be pip.

I did the following steps to get virtualenv working :
Update virtualenv as follows :
==> sudo pip install --upgrade virtualenv
Initialize python3 virtualenv :
==> virtualenv -p python3 venv

I had this same issue, and I can confirm that the problem was with an outdated virtualenv.py file.
It was not necessary to do a whole install --upgrade.
Replacing the virtualenv.py file with the most recent version sufficed.

I also had this problem, and I tried the following method which worked for me:
conda install virtualenv
virtualenv --system-site-packages /anaconda/envs/tensorflow (here envs keeps all the virtual environments made by user)
source /anaconda/envs/tensorflow/bin/activate
Hope it's helpful.

I had this same issue when trying to install py2.7 on a newer system. The root issue was that virtualenv was part of py3.7 and thus was not compatible:
$ virtualenv -p python2.7 env
Running virtualenv with interpreter /usr/local/bin/python2.7
New python executable in /Users/blah/env/bin/python
ERROR: The executable /Users/blah/env/bin/python is not functioning
ERROR: It thinks sys.prefix is u'/Library/Frameworks/Python.framework/Versions/2.7' (should be u'/Users/blah/env')
ERROR: virtualenv is not compatible with this system or executable
$ which virtualenv
/Library/Frameworks/Python.framework/Versions/3.7/bin/virtualenv
# install proper version of virtualenv
$ pip2.7 install virtualenv
$ /Library/Frameworks/Python.framework/Versions/2.7/bin/virtualenv -p python2.7 env
$ . ./env/bin/activate
(env) $

Open terminal and type /Library/Frameworks/Python.framework/Versions/
then type ls /Library/Frameworks/Python.framework/Versions/2.7/bin/
if you are using Python2(or any other else).
Edit ~/.bash_profile and add the following line:
export PATH=$PATH:/Library/Frameworks/Python.framework/Versions/2.7/bin/
cat ~/.bash_profile
In my case the content of ~/.bash_profile is as follows:
export PATH=$PATH:/Library/Frameworks/Python.framework/Versions/2.7/bin/
Now the virtualenv command should work.

If you continue to have trouble with virtualenv, you might try pythonbrew, instead. It's an alternate solution to the same problem. It works more like Ruby's rvm: It builds and creates an entire instance of Python, under $HOME/.pythonbrew, and then sets up some bash functions that allow you to switch easily between versions. Where virtualenv shadows the system version of Python, using symbolic links as part of its solution, pythonbrew builds entirely self-contained installations of Python.
I used virtualenv for years. It's a decent solution, but I've switched to pythonbrew lately. Having completely self-contained Python instances means that installing a new one takes awhile (since pythonbrew actually compiles Python from scratch), but the self-contained nature of each installation appeals to me. And disk is cheap.