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:
pyvenv.cfgfile points to the Python installation that you used to run the command.
libsubdirectory contains a copy of the Python version and has a
site-packagessubdirectory inside it that starts out empty but will eventually hold the relevant third-party modules that you install.
includesubdirectory compiles packages.
binsubdirectory 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
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.
Within the virtual environment, you can use the command
python instead of
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
pip3 commands exclusively, as
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