In this post, I’d like to outline how to create and manage virtual environments each with its own, independent set of dependencies with the following packages:
- pip, A tool for installing and managing Python packages in the Python Package Index
- virtualenv, A tool for creating isolated Python environments containing their own copy of python, pip, and other packages
- virtualenvwrapper, A set of convenient enhancements to virtualenv
virtualenvwrapper is a set of extensions to Ian Bicking’s virtualenv tool. The extensions include wrappers for creating and deleting virtual environments and otherwise managing your development workflow, making it easier to work on more than one project at a time without introducing conflicts in their dependencies.
The rationale behind virtual environments is to make available reproducible, isolated sets of dependencies/python packages without much configuration and without having to watch and manage the packages’ different versions.
We can have an isolated environment for each program, each containing a complete copy of everything needed to run that Python program, including the python binary itself. This allows you to effectively work on two different programs with two different sets of dependencies all on the same machine.
Before we begin, type
pip freeze to get the currently installed packages in your system. We will use this information for later comparison.
The subset of
virtualenvwrapper commands we will be using are:
Having installed all the above packages (pip, virtualenv, virtualenvwrapper) in your system, let’s start by creating a new virtual environment:
mkvirtualenv command creates does a couple of things:
- Creates a new environment folder in your
- Installs a new python binary into your new environment
pipinto your new environment
- Activates the environment
You should now see
(myenv) on the left side of your shell prompt. This tells you that you currently have that virtual environment active.
So now, when we type
pip freeze, we get:
wsgiref? Wait, shouldn’t a fresh virtual environment be completely free of packages? The reason wsgiref appears is because
python 2.5+ standard library provides egg info to
wsgireflib (and pip does not know if it
stdlib or 3rd party package). Since this is the only package in our virtual environment, it’s safe to consider it as ‘fresh.’
Now, let’s install a package into our new virtual environment:
Let’s see what packages our virtual environment now have:
You can install however many packages and versions of packages you’d like into your virtualenv without affecting any of your system’s packages.
What if we have multiple projects, each with its own set of dependencies? We are not limited to one virtualenv. We can type workon to see all of our virtual environments:
We can switch to my other, pre-existing virtualenv
'django’ which has its own set of dependencies installed:
Now, let’s say that you’ve been working on your project with this virtual environment, and now you’d like to invite another developer to work on your project. How can she reproduce your virtual environment on her machine? Short answer: Requirements files.
Requirements files are plain text files that contain a list of packages to be installed and can be easily created by piping the output of pip freeze into a .txt file.
Other developers can reproduce your virtual environment by creating a fresh virtual env and running a pip install with your requirements file:
Finally, you can deactivate your virtual environment and return to your system environment with the following command:
To sum up, using
virtualenvwrapper, and requirements files helps you create isolated, reproducible environments with minimal effort.
You can read up more on advanced features of
virtualenvwrapper, such as the
postmkproject virtualenv hooks here.
Additional reading: - Doug Hellmann on virtualenvwrapper
📬 Subscribe to my newsletter
Get notified of my latest articles by providing your email below.