The most common reason for this is that you have two versions of Python 2.x, and the
pip that comes first in your
PATH doesn’t go with the
python that comes first in your
There are two ways that can happen.
First, you may have, e.g.,
/usr/bin on your
PATH, but your
/usr/local copy of Python doesn’t have
pip. So, when you run
pip install requests, that’s
/usr/bin/pip, which installs into
/usr/lib/python2.7/site-packages. But when you run
/usr/local/bin/python, which looks in
Second, even though your two Python 2.x’s are in different locations, they may want to install
pip (and other scripts and executables) to the same place. In particular,
/usr/bin is usually reserved for stuff that comes with the OS or its package manager, so if you use
/usr/bin/python ez_setup.py or
/usr/bin/easy_install pip or many other common ways to install
pip, it may end up in
/usr/local/bin. In which case it will overwrite any earlier
/usr/local/bin/pip that went with your
/usr/local/bin/python. At any rate, the result is basically the same:
pip now means
/usr/local/bin/pip, but it still goes with your
/usr Python, not your
/usr/local Python, and installs into
/usr/local/bin/python can’t see.
If your two versions are, e.g., 2.7 and 3.4, there’s no problem; per PEP 394, either the 3.x versions of everything have to be run with
pip3 and so on, or the 2.x versions have to be run with
pip2 and so on.
If your two versions are, e.g., 2.6 and 2.7, there is a problem, but you can easily work around it, because you should always have
python2.7. You can confuse yourself with
pip, but you don’t have to.
If your two versions are both 2.7, however, there’s no way to disambiguate (except by using complete absolute paths all the time, which no one wants to do).
So, why would anyone ever install two copies of Python 2 without knowing what they’re doing?
The most common reason is that they’re on a Mac, which comes with Python 2.7, but they read a blog post that told them to install another Python and didn’t explain how to know what they’re doing. Apple’s pre-installed Python is in /usr/bin but installs scripts and binaries to
/usr/local/bin. The most popular alternative Python versions are the python.org installer and Homebrew, both of which install to
/usr/local/bin by default. The fact that Mac users tend to be less Unix-savvy than Linux or FreeBSD users probably doesn’t help, but even without that, this is a perfect way to end up with thousands of people who have a
pip and a
python that doesn’t match, and no idea why.
There used to be good reasons for almost all Mac Python users to installing a second Python. Until OS X 10.6, Apple’s pre-installed Python versions tended to be badly out of date, and sometimes broken. If Apple’s only giving you 2.4, it makes sense to install 2.6. And doing so is no problem, because
python2.6 are easy to disambiguate. But Apple has been installing a working 2.7 for years now. There are sometimes good reasons why you need a different one (you need a bug fix in 2.7.7 but Apple gave you 2.7.5, you need a 32-bit build, you need an extra-batteries version like Enthought, you need to build
py2app bundles out of it, …), but these reasons do not apply to most people anymore.
In fact, many people on StackOverflow seem to have three versions of Python 2.7. I’m not sure why this is so common, but they’ll use Homebrew to install Python 2.7, and then use an installer from Python.org or Enthought, and now they’ve got three Python 2.7 versions all fighting over ownership of /usr/local/bin.
So, how can you fix this?
- If you can use Python 3.x, install that and just use
ipython3and so on), and paths aren’t an issue anymore.
- If you don’t need a second Python 2.7, get rid of the non-Apple one and just use Apple’s.
- Otherwise, do not ever use Apple’s Python, do not install things for it, do not touch it; just leave it alone for Apple’s own tools. If you use Homebrew, its Python should be higher on the PATH (make sure you’ve got
/usr/bin), and it should let you
pip install foowithout
sudo, while Apple’s won’t, which makes it hard to accidentally screw up and install to the wrong one.
I’ve also seen at least one Windows user who had both
D:\Python27, both on the
PATH, with the
C: one first, but
pip only installed for
D:. This seems to be far less common than the Mac confusion (probably because Windows doesn’t come with Python, and there are no package managers, so the only way you’re going to get any Python is by running an installer). And the solution is even simpler here: Windows doesn’t need Python, so you can delete whichever one you want.
Finally, on non-Mac *nix systems, especially RHEL/CentOS Linux, you may have a Python 2.6 or 2.4 that’s needed by the OS plus a Python 2.7 that you installed because you needed it, or a 2.7 that’s needed by the OS and a 2.5 installed as a dependency for some “compatibility” package, or similar. Either way, you can easily accidentally install the
pip for the one you don’t actually use (especially if you install it with the
pip bootstrap instead of your package manager).
The solution here is pretty simple: uninstall that
pip, and use
apt or whatever to install the
python-pip that goes with the Python 2.7 you want to use. And get in the habit of using
pip2.7—or just add aliases to your profile so that
py or whatever you prefer runs