pip installing in global site-packages instead of

Question

Using pip to install a package in a virtualenv causes the package to be installed in the global site-packages folder instead of the one in the virtualenv folder. Here's how I set up Python3 and virtualenv on OS X Mavericks (10.9.1):

I installed python3 using Homebrew:

ruby -e "$(curl -fsSL https://raw.github.com/Homebrew/homebrew/go/install)"
brew install python3 --with-brewed-openssl

Changed the $PATH variable in .bash_profile; added the following line:

export PATH=/usr/local/bin:$PATH

Running which python3 returns /usr/local/bin/python3 (after restarting the shell).

Note: which python3 still returns /usr/bin/python though.

Installed virtualenv using pip3:

pip3 install virtualenv

Next, create a new virtualenv and activate it:

virtualenv testpy3 -p python3
cd testpy3
source bin/activate

Note: if I don't specify -p python3, pip will be missing from the bin folder in the virtualenv.

Running which pip and which pip3 both return the virtualenv folder:

/Users/kristof/VirtualEnvs/testpy3/bin/pip3

Now, when I try to install e.g. Markdown using pip in the activated virtualenv, pip will install in the global site-packages folder instead of the site-packages folder of the virtualenv.

pip install markdown

Running pip list returns:

Markdown (2.3.1)
pip (1.4.1)
setuptools (2.0.1)
virtualenv (1.11)

Contents of /Users/kristof/VirtualEnvs/testpy3/lib/python3.3/site-packages:

__pycache__/
_markerlib/
easy_install.py
pip/
pip-1.5.dist-info/
pkg_resources.py
setuptools/
setuptools-2.0.2.dist-info/

Contents of /usr/local/lib/python3.3/site-packages:

Markdown-2.3.1-py3.3.egg-info/
__pycache__/
easy-install.pth
markdown/
pip-1.4.1-py3.3.egg/
setuptools-2.0.1-py3.3.egg
setuptools.pth
virtualenv-1.11-py3.3.egg-info/
virtualenv.py
virtualenv_support/

As you can see, the global site-packages folder contains Markdown, the virtualenv folder doesn't.

Note: I had Python2 and Python3 installed before on a different VM (followed these instructions) and had the same issue with Python3; installing packages in a Python2 based virtualenv worked flawlessly though.

Any tips, hints, … would be very much appreciated.

Answer 1

I had the same problem, I solved it by removing venv directory and recreating it!

deactivate (if venv is activated first deactivate it)
rm -rf venv
virtualenv -p python3 venv
. ENV/bin/activate
pip3 install -r requirements.txt

Now everything works like a charm.

Answer 2

I had this problem. It turned out there was a space in one of my folder names that caused the problem. I removed the space, deleted and reinstantiated using venv, and all was well.

Answer 3

Came across the same issue today. I simply reinstalled pip globally with sudo easy_install pip (OSX/ Max), then created my virtualenv again with sudo virtualenv nameOfVEnv. Then after activating the new virtualenv the pip command worked as expected.

I don't think I used sudo on the first virtualenv creation and that may have been the reason for not having access to pip from within the virtualenv, I was able to get access to pip2 before this fix though which was odd.

Answer 4

It's also worth checking that you didn't modify somehow the path to your virtualenv.

In that case the first line in bin/pip (and the rest of the executables) would have an incorrect path.

You can either edit these files and fix the path or remove and install again the virtualenv.

Answer 5

None of the above solutions worked for me.

My venv was active. pip -V and which pip gave me the correct virtualenv path, but when I pip install-ed packages with activated venv, my pip freeze stayed empty.

All the environment variables were correct too.

Finally, I just changed pip and removed virtualenv:

easy_install pip==7.0.2

pip install pip==10

sudo pip uninstall virtualenv

Reinstall venv:

sudo pip install virtualenv

Create venv:

python -m virtualenv venv_name_here

And all packages installed correctly into my venv again.

Answer 6

I had this problem too. Calling sudo pip install caused Python packages to be installed in the global site-packages diretory and calling pip install just worked fine. So no use sudo in virtualenv.