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

Funny you brought this up, I just had the exact same problem. I solved it eventually, but I'm still unsure as to what caused it.

Try checking your bin/pip and bin/activate scripts. In bin/pip, look at the shebang. Is it correct? If not, correct it. Then on line ~42 in your bin/activate, check to see if your virtualenv path is right. It'll look something like this

VIRTUAL_ENV="/Users/me/path/to/virtual/environment"

If it's wrong, correct it, deactivate, then . bin/activate, and if our mutual problem had the same cause, it should work. If it still doesn't, you're on the right track, anyway. I went through the same problem solving routine as you did, which piping over and over, following the stack trace, etc.

Make absolutely sure that

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

is what you want, and not referring to another similarly-named test project (I had that problem, and have no idea how it started. My suspicion is running multiple virtualenvs at the same time).

If none of this works, a temporary solution may be to, as Joe Holloway said,

Just run the virtualenv's pip with its full path (i.e. don't rely on searching the executable path) and you don't even need to activate the environment. It will do the right thing.

Perhaps not ideal, but it ought to work in a pinch.

Link to my original question:

VirtualEnv/Pip trying to install packages globally

Answer 2

I had a similar problem after updating to pip==8.0.0. Had to resort to debugging pip to trace out the bad path.

As it turns out my profile directory had a distutils configuration file with some empty path values. This was causing all packages to be installed to the same root directory instead of the appropriate virtual environment (in my case /lib/site-packages).

I'm unsure how the config file got there or how it had empty values but it started after updating pip.

In case anyone else stumbles upon this same problem, simply deleting the file ~/.pydistutils.cfg (or removing the empty config path) fixed the problem in my environment because pip went back to the default distributed configuration.

Answer 3

I had this problem too. Calling pip install <package_name> from the /bin directory within my Python 3.3 virtual environment on my Mavericks Mac caused the Python package to be installed in the Python 2.7 global site packages directory. This was despite the fact that my $PATH started with the directory containing pip. Weird. This doesn't happen on CentOS. For me, the solution was calling pip3 instead of pip. When I had installed pip within the virtual environment via ez_setup, three "pip" executables had been installed in the /bin directory - pip, pip3, and pip3.3. Curiously, all three files were exactly the same. Calling pip3 install <package_name> caused the Python package to be installed correctly into the local site-packages directory. Calling pip with the full pathname into the virtual environment also worked correctly. I'd be interested to know why my Mac isn't using $PATH the way I would expect it to.

Answer 4

It happened to me when I installed virtualenv with --python=python3.6 flag but afterwards tried to use pip2 install.
Creating virtualenv with flag of the version that you'll use solves permission problems. To check, try which pip or which pip2 or which pip3 (depends on your choice). If any pip you use shows path not to venv here is your problem.

Answer 5

For me this was not a pip or virtualenv problem. It was a python problem. I had set my $PYTHONPATH manually in ~/.bash_profile (or ~/.bashrc) after following some tutorial online. This manually set $PYTHONPATH was available in the virtualenv as it probably should be allowed.

Additionally add2virtualenv was not adding my project path to my $PYTHONPATH for some reason within the virtualenv.

Just some forking paths for those who might still be stuck! Cheers!

Answer 6

For Python 3ers

Try updating. I had this exact same problem and tried Chases' answer, however no success. The quickest way to refactor this is to update your Python Minor / Patch version if possible. I noticed that I was running 3.5.1 and updated to 3.5.2. Pyvenv once again works.