In this post, we’ll be looking at the virtualenv package.

Its use is fairly standard as it solves a common problem when programming in Python.

As mentioned in Part 1, Python imports modules by looking through a list of directory paths. What happens when two modules have the same name? You could introduce some logic into your script to ensure the right module is imported, but this is time consuming, error prone and quickly gets out of hand for large projects.

Suppose you’re using an API and your scripts import several modules from it. The version of the API you’re using is going to be sunset. You could remove the current package and replace it with the new one, but this risks breaking things as changes may be required before your current project is compatible with the new API.

You decide to download the new package as well, i.e. have both in your global environment. That way you can make the necessary changes to ensure compatibility with the new API whilst ensuring everything still functions as before with the old API.

However, when you import a module, it’s not clear which version of the API you’re using. One solution is to separate your projects into virtual environments. Each one contains a copy of the Python interpreter, pip, and installed packages that is completely independent of those on the global environment as well as all other virtual environments.

The virtualenv package should already be installed. To confirm,

As per usual,

provides a useful summary of the package’s functionality. Each virtual environment is a directory. To keep things organised,

This creates a hidden folder in the user’s home directory in which all the virtual environments are going to be saved. To create a virtual environment in that directory

To delete it

To activate it, run the ‘activate’ executable

If successful, the shell prompt changes to

With the virtual environment activated, the interpreter, pip, list of installed packages are all specific to that environment, e.g.

returns the packages installed for the virtual environment ‘myvenv’.

To install a package in the virtual environment currently activated,

As this is not a global installation, there are no permissioning issues like before. This installs the package to

To uninstall,

To exit the virtual environment,

In the next post, we’ll take a look at the virtualenvwrapper package which makes using virtualenv (even) easier.