Python sports a concept called the virtual environment. It is sometimes called a “virtualenv” or a “venv”. You can think of a virtual environment as a kind of lightweight container for a Python application, where the appliction can see its own particular set of Python libraries, at specific versions. This provides some significant benefits for deployment:
Dependencies can be precisely tracked and specified, and even kept in version control.
Two different Python applications with conflicting dependencies can peacefully coexist on the same machine.
Python packages can be installed without requiring elevated system privileges.
How you create a virtual environment depends on whether you’re using Python 3 or 2. For Python 3, you invoke python -m env, adding one more argument – the name of a folder to create:
# The recommended method in Python 3.
$ python3 -m venv webappenv
(The $ is the shell prompt.) For the near future, you can also use the pyenv command. This works fine, but is deprecated, and scheduled to disappear in Python 3.8:
# Does the same thing, but is deprecated.
$ pyenv webappenv
What these both do is create a folder named “webappenv” in the current directory. The Python 2 tool, virtualenv, has the same interface; wherever you see python -m venv in this book, you an substitute virtualenv instead:
# Same as the above, in Python 2.
$ virtualenv webappenv
Regardless of which you use, you’ll end up with a new folder named webappenv, containing all sorts. To access them, you must run a script called “activate”. In macOS and Linux, type the following in your shell:
$ source webappenv/bin/activate
For Windows, run the script webappenvScriptsactivate.bat instead:
Notice your prompt has changed: now it contains (webappenv). The script called activate did not start a new shell or session; all it did was alter your PATH and PYTHONPATH environment variables, and a few others (like the PS1 variable, which specifies how your shell renders the prompt.) You just activated your virtual environment, as we say. When it’s active for that particular shell session, we say you are working in the virtual environment.
Suppose your system Python executable is at /usr/bin/python3 (or /usr/bin/python for version 2). And suppose you’ve created the webappenv folder in /Users/paul/mywebapp/webappenv. With the virtual environment activated, you have your own local copy of the Python interpreter. You can check this with the which command on macOS and Linux:
(webappenv)$ which python
(webappenv)$ python -V
Or the where command on Windows:
(webappenv) C:labs> where python
This is for the virtual environment we created with pyenv, which means it’s Python 3. Now, what if you want to restore your old PATH (and PYTHONPATH, etc.)? Within the virtualenv, you now have a function defined called deactivate:
$ which python
Now imagine you are writing a Python application: let’s call it mediatag, one designed for tagging files in your media collection: It’s implemented in Python 2.7. We can do the following:
$ cd /Users/paul/mediatag
$ virtualenv mediatagenv
$ source mediatagenv/bin/activate
(mediatagenv)$ which python
(mediatagenv)$ python -V
This shows one minor benefit of virtual environments: it provides a new way to control the precise version of Python used by an application. But the main benefit for using virtual environments has to do with resolving requirements, upgrades, and dependencies with packages and libraries.