Creating Python Virtual Environments

Python applications will often use packages and modules that don't come as part of the standard library. Applications will sometimes need a specific version of a library, because the application may require that a particular bug has been fixed or the application may be written using an obsolete version of the library's interface.

This means it may not be possible for one Python installation to meet the requirements of every application. If application A needs version 1.0 of a particular module but application B needs version 2.0, then the requirements are in conflict and installing either version 1.0 or 2.0 will leave one application unable to run.

The solution for this problem is to create a virtual environment, a self-contained directory tree that contains a Python installation for a particular version of Python, plus a number of additional packages.

You can setup as many Python programming environments as you would like. Each environment is basically a directory or folder that in your computer that has a few scripts in it to make it act as an environment.

Choose which directory you would like to put your Python programming environment in, or create a new directory:

  $> mkdir Playground
  $> cd Playground

Once you are in the directory where you would like the environments to live, you can create an environment by running the following command:

  $> python3 -m venv learning_env

Essentially, this command creates a new directory (in this case called learning_env) that contains a few items:

The pyvenv.cfg file points to the Python installation that you used to run the command.
The lib subdirectory contains a copy of the Python version and has a site-packages subdirectory inside it that starts out empty but will eventually hold the relevant third-party modules that you install.
The include subdirectory compiles packages.
The bin subdirectory has a copy of the Python binary along with the activate shell script that is used to set up the environment. Together, these files work to make sure that your projects are isolated from the broader context of your local machine, so that system files and project files don’t mix. This is a good practice for version control and to ensure that each of your projects has access to the particular packages that it needs.

To use this environment, you need to activate it, which you can do by typing the following command that calls the activate script:

  $> source learning_env/bin/activate

Your prompt will now be prefixed with the name of your environment, in this case it is called learning_env:

  (learning_env) $>

This prefix lets us know that the environment learning_env is currently active, meaning that when we create programs here they will use only this particular environment’s settings and packages.

Note

Within the virtual environment, you can use the command python instead of python3, and pip instead of pip3 if you would prefer. If you use Python 3 on your machine outside of an environment, you’ll need to use python3 and pip3 commands exclusively, as python and pip will call an earlier version of Python.

After following these steps, your virtual environment is ready to use.

  (learning_env) $> python --version
  Python 3.9.1

To leave the environment, simply type the command deactivate and you’ll return to your original directory.

  (learning_env) $> deactivate
  $> python --version
  Python 2.7.16