Restricting pip to virtual environments
What happens if we think we are working in an active virtual environment, but there actually is no virtual environment active, and we install something via pip install foobar? Well, in that case the foobar package gets installed into our global site-packages, defeating the purpose of our virtual environment isolation.
In an effort to avoid mistakenly pip-installing a project-specific package into my global site-packages, I previously used easy_install for global packages and the virtualenv-bundled pip for installing packages into virtual environments. That accomplished the isolation objective, since pip was only available from within virtual environments, making it impossible for me to pip install foobar into my global site-packages by mistake. But easy_install has some deficiencies, such as the inability to uninstall a package, and I found myself wanting to use pip for both global and virtualenv packages.
Thankfully, pip has a sparsely-documented setting that tells it to bail if there is no active virtual environment, which is exactly what I want. In fact, we’ve already set that above, via the export PIP_REQUIRE_VIRTUALENV=true directive. For example, let’s see what happens when we try to install a package in the absence of an activated virtual environment:
$ pip install markdown
Could not find an activated virtualenv (required).
Perfect! But once that option is set, how do we install or upgrade a global package? We can temporarily turn off this restriction by adding the following to your ~/.bashrc:
PIP_REQUIRE_VIRTUALENV=”” pip ”$@”
If in the future we want to upgrade our global packages, the above function enables us to do so via:
syspip install —upgrade pip setuptools virtualenv
You could, of course, do the same via PIP_REQUIRE_VIRTUALENV=”” pip install —upgrade foobar, but that’s much more cumbersome to type.
virtualenv is a tool that allows you to create isolated Python environments, each with its own set of packages and dependencies. This is useful for testing or managing package requirements (for example, if you build an application that is dependent on a certain version of a third-party package but another application requires a more recent version, you might break the first application by upgrading). This is not required, and all the commands below should work whether or not you are using virtualenv, so consider this step for convenience only. The only difference will be that directories (such as that returned bywhich pip) will point to the virtualenv rather than /usr/local.
First, install virtualenv and virtualenvwrapper, a tool that makes working with virtualenv somewhat easier:
Next, source the virtualenvwrapper script:
This will create a (hidden) virtualenv directory at ~/.virtualenv. Now you can create your first virtual environment:
Your new virtualenv test1 comes with a complete install of Python 2.7.3 and its own version of pip. It is activated by default, so running any pipcommand will only impact this environment. Note that if you deactivatethe virtualenv, you will lose access to any packages installed in it. You can switch between virtualenvs with the workon command. To delete your test virtualenv, run rmvirtualenv test1.