Question

Assume I have a virtualenv installation that does not use --no-site-packages. I run bin/pip install somepackage==1.0.0, but it’s already present in my site-packages so it’s not installed. Later, the copy installed site-packages is updated to somepackage==2.0.0.

What will happen in my virtualenv? Will it use the version 2, or download version 1 for itself?

Answer 1

It depends. If none of the packages that are importing somepackage use the setuptools API, then it works as described above. If any packages in your virtualenv use setuptools (or Distribute) to specify specific version requirements for somepackage, setuptools will search for a version of somepackage that meets the requirements. If it can’t find a suitable installed version at install time, it will search externally and attempt to install it. If it can’t find one at runtime, the program fails with an exception.

from setuptools import setup
setup(
    name = "HelloWorld",
    version = "0.1",
    scripts = ['say_hello.py'],
    install_requires = ['somepackage == 1.0.0'],
)

For example, if somepackage 1.0.0 was already installed in the system site-packages, everything is fine. If you then update the system site-packages to somepackage 2.0.0 with pip, which uninstalls the old version, the script will fail at runtime with:

pkg_resources.DistributionNotFound: somepackage==1.0.0

If you installed both versions of somepackage with easy_install instead of pip, things would normally be different. By default, easy_install does not uninstall packages and it supports multiple versions of packages (multi-version eggs). So both versions of somepackage would be available in the system site-packages and the script would not fail.

setuptools (and the Distribute clone of it) has to jump through many hoops to make the multiple version support work reasonably. Many developers frown on all that extra complexity and argue that it is easier and more transparent to support multiple versions of packages with separate virutalenv‘s and, for that, the simpler model of pip is more appropriate. (In fairness to setuptools, virtualenv came along later.)