Dependency sandboxing with virtualenv

So you have installed all the packages that you want for your new project. Great! But what happens when we develop a second project some time later that will use newer versions of the same packages? And what happens when a library that you wish to use depends on a library that you installed for the first project, but which uses an older version of these packages? When newer versions of packages contain breaking changes, upgrading them would require extra development work on an older project that you may not be able to afford. So in our system, we could have clashing Python packages between projects.

We should also consider automated build environments, such as Jenkins, where we want to run tests. These builds may run on the same system on which other projects are being built, so it's essential that during the build jobs we create a contained Python package environment that is not shared between jobs. This environment is created from the information in the requirements.txt file that we created earlier. This way, multiple Python applications can be built and tested on the same system without clashing with each other.

Thankfully, there is virtualenv, a tool that sandboxes your Python projects. The secret to virtualenv is in tricking your computer to look for and install packages in the project directory rather than in the main Python directory, which allows you to keep them completely separate.

If you're using Python 3—and I recommend that you do, because Python 2 support will end in 2020—then you don't have to install virtualenv; you can use it just by running it like a package, as shown in the following code:

# Create a python 3 virtualenv
$ python3 -m venv env

Now that we have pip, if we need to install virtualenv, then we can just run the following command:

$ pip install virtualenv

Virtualenv basics

Let's initialize virtualenv for our project, as follows:

$ virtualenv env

The extra env tells virtualenv to store all the packages in a folder named env. Virtualenv requires you to start it before it will sandbox your project. You can do this using the following code:

$ source env/bin/activate
# Your prompt should now look like
(env) $

The source command tells Bash to run the env/bin/activate script in the context of the current directory. Let's reinstall Flask in our new sandbox, as follows:

# you won't need sudo anymore
(env) $ pip install flask
# To return to the global Python
(env) $ deactivate