As your Python projects grow in complexity, you may find yourself needing to manage multiple versions of packages and Python itself. Virtualenvs allow you to create isolated Python environments to keep dependencies separate. However, replicating an environment manually is tedious. Luckily, there are simpler methods to duplicate your virtualenv.
First, a quick overview of key concepts. A virtualenv enables you to install Python packages in an isolated location without impacting other environments. For example, you can maintain a legacy project with old package versions, while also working on a modern Python 3.8 application with the latest packages. The virtualenv command creates these sandboxed environments.
Furthermore, virtualenvwrapper provides convenient management tools for working with virtualenvs. In particular, the mkvirtualenv command sets up new virtualenvs, while the workon command lets you activate existing ones. Additionally, virtualenvwrapper stores all virtualenvs in one central location instead of the current working directory.
Prerequisites – Virtualenv
Before cloning a virtualenv, you need:
- Python and virtualenv/virtualenvwrapper installed
- The existing “source” virtualenv you want to copy
- Enough disk space for another copy of the environment
With those covered, we’re ready to duplicate. There are a few approaches we can take, starting simple.
The Basic Method
The most straightforward technique uses virtualenv directly:
- Activate the sourceVirtualenv:
- Deactivate it:
- Clone the environment:
virtualenv --python=$(which python) --relocatable cloned_env
This creates cloned_env as a separateVirtualenv bundled with the same Python version.
However, there are some downsides:
- No packages are installed in the cloned environment.
- Site package dependencies may break if moved to another system.
So while simple, we need to extend this further.
We can improve portability by passing another flag:virtualenv –python=$(which python) –relocatable –always-copy cloned_env
The –always-copy option forces normally system-level packages into the virtualenvs site packages. This self-contained bundle can then move between systems without breaking.
To finish, we’ll need to install the packages.
Installing Dependencies – Virtualenv
With our clonedVirtualenv ready, there are two options to populate it with the source environment’s packages:
Option 1: requirements.txt
- Activate the source virtualenv
- Export installed packages
pip freeze > requirements.txt
- Activate the cloned virtualenv
- Install from file
pip install -r requirements.txt
By leveraging pip freeze, we can automate environment replication via requirements files.
Option 2: Virtualenv Plugins
Extensions likeVirtualenv-clone and virtualenvwrapper-clone eliminate the manual steps above:
virtualenvwrapper-clone source_env cloned_env
Simply invoke the clone command on an existingVirtualenv, and both environments match. Any new packages install only in the activeVirtualenv, keeping them separated.
Migrating Virtualenvs dependencies takes only a few commands, but vastly simplifies Python environment management. First create an isolated duplicate environment with virtualenv’s relocatable option. Then populate it via automated requirements or dedicated clone tools.
Now you’re ready to upgrade individual packages like Django without impacting legacy systems. Virtualenvs enable you to progress projects forward without risky changes, just by duplicating existing ones.