Python allows a developer to create virtual environments that collect up all the baseline language facilities and functionality into a single location. Once set up, those virtual environments have packages installed in to or removed from them, which allows a project that's executing in the context of the environment to have access to packages and functionality that may not be needed in the base system. A virtual environment also provides a mechanism for keeping track of those installations, which in turn allows a developer to keep track of only those dependencies and requirements that are relevant to the project itself.

Virtual environments can also be used, with some care and thought, to allow a project to be developed against a specific version of the Python language – one that's no longer supported, for example, or that's still too new to be available as a standard installation in the development machine's OS. This last aspect can be very useful in developing Python applications to run in various public clouds such as Amazon's AWS, where the Python version may be newer than what's generally available, and may also have significant syntax differences from earlier versions of the language.

Provided that the appropriate Python module (venv in Python 3) is already installed, creating a virtual environment, activating, and deactivating it at a command-line level is pretty straightforward:

python3 -m venv ~/py_envs/example_ve

Creates a new, minimal virtual environment at the specified location (in this case, in a directory named example_ve, in a directory named py_envs in the user's home directory):

source ~/py_envs/example_ve/bin/activate

This activates the newly created virtual environment. At this point, launching python shows that it's using version 3.5.2, and the command line interface prefaces each line with (example_ve) to show that the virtual environment is active:

deactivate

This deactivates the active virtual environment. Launching python from the command-line now shows the default Python version, 2.7.12, for the system.

Installing, updating, and removing packages, and showing what packages are installed, are equally straightforward:

This activates the virtual environment again:

source ~/py_envs/example_ve/bin/activate

This shows the list of currently installed packages. It does not show any of the packages that are part of the core Python distribution, only those that have been added. 

pip freeze

The first run, in this case, also notes that the current version of pip in the environment is old and can be updated, which is done with this command:

pip install –upgrade pip

The pip package itself is part of the base Python installation, and even though it's just been updated, that has no effect on the list of packages returned by calling pip freeze again.

To illustrate how pip deals with installation of new packages, the pillow library, a Python API for working with graphics files, was installed with this:

pip install pillow

Since pillow is not a standard library, it does appear in the results of another pip freeze call. The results of pip freeze can be dumped to a requirements file (requirements.txt, for the purposes of illustration) as part of a project structure, and stored with the project, so that package dependencies don't actually have to live in the source tree of the project, or be stored with it in an SCM. That would allow a new developer on a project to simply create their own virtual environment, then install the dependencies with another pip call:

pip install -r requirements.txt

The pillow library was then uninstalled to show what that looks like, with this:

pip uninstall pillow

Virtual environments, then, allow for a lot of control over what third-party packages can be associated with a project. They come with a small price, though: they have to be maintained, if rarely, and as changes to those external packages are made by one developer, some discipline needs to be exerted to make sure that those changes are available for other developers working on the same code base.