Virtual environments in Python¶

Python, like other programming languages, has its own way of managing libraries and importing their dependencies into the module. Due to the huge number of packages that perform various tasks, developers have divided them into two categories: internal (standard, built-in) and external libraries. All downloaded libraries are located in the directory: \Lib\site-packages (Windows) or /site-packages (Linux) in the Python root folder and from there the interpreter navigates them and add to the project whenever it comes across the import command in a file. For easier library management and to prevent any ambiguity from appearing, only one version of a specific downloaded package can be found in the \ Lib \ site-packages directory (how would Python know which version we want to import into the program?). Such architecture, draws programmers into a completely different problems. It is not uncommon to work on several projects in parallel, and each of them may require the same libraries, but - for example - in completely different, incompatible versions. Does this mean that it is necessary to work on other programs on separate machines?

Virtual environment¶

The main purpose of Python's virtual environments is to create an isolated library space for ongoing projects. This means that each project can have its own dependencies, regardless of which packages are used by other programs created in parallel.

The great thing is that there is no limit to the number of environments that can be created on one computer. From the operating system's point of view, virtual environments are seen as ordinary directories containing several scripts. They can be easily created by using specially dedicated tools such as virtualenv or virtulenvwrapper.

virtualenv¶

By default, pip will install packages globally for the entire system. As mentioned earlier: in most cases this is not the desired action. We can have many different projects on the computer - each with its own set of dependencies.

In order to separate one project from another, it is necessary to create environments for each programming solution. Within these environments, each project will be able to have its own, not shared to anyone, list of installed libraries only for its use. And it doesn't matter that globally or in another environment these libraries are also available, but in different versions. Isolation works, which means that projects interfere each other.

To achieve this, tools for managing virtual environments, such as virtualenv helps.

The idea of a virtual environment is presented simply in one picture:

Basic operations: installation¶

To install the virtualenv package, usepip and use the command:

pip install virtualenv

This is the only library that should be installed globally on the system. Thanks to this, we don't allow Python to store any other libraries in a place accessible to all projects, which will prevent any future version conflicts.

Basic operations: creation¶

To create virtual environment use command:

virtualenv <environment_name> or python -m venv <environment_name>.

The above commands will create a new virtual environment with the selected name: it will be a folder with three consecutive directories inside (first the names of the directories from Linux are given, the second from Windows):

• bin/Scripts - contains files that interact with the virtual environment (e.g. script to activate the environment),
• include/Include - C language code files for compiling packages,
• lib/Lib - copy of the / site-packages folder.

The most common way to name virtual environments is simply to give it the name venv , so that every programmer peeking into the project will properly recognize its folder.

It is recommended to create the environment command (adding a new directory as a result) in the main folder of the project for which it is created.

Basic operations: activation¶

In order to find yourself in a virtual environment, you must activate it. This is done with the command:

• For Windows:

C:\path\to\environment\environment_name\Scripts\activate.bat

• For Linux/Mac:

source ./path/to/environment/environment_name/bin/activate

If we have several versions of Python on the computer, we can decide which one to use in the environment, specifying the path in the parameter -p, i.e.:

source ./path/to/environment/environment_name/bin/activate -p /path/to/version/Python/python

If virtualenv has been successfully activated, the command line will now have its name in brackets on the left until it leaves the environment.

The pip freeze command should return an empty list.

Basic operations: library installation¶

Once we're in a virtual environment, we can normally install packages using the pip tool. All features of this tool are allowed:

• a simple pip install command,
• searching, listing existing libraries, uninstalling packages,
• using the requirements.txt file,
• creating your own files that store dependencies.

Basic operations: deactivation¶

If you need to switch to another virtual environment (with other packages installed), leave the currently running one. Use this command:

deactivate

Basic operations: deactivation continued.¶

For the deactivate command to work, you must be in any virtual environment!

virtualenv - summary¶

So far, the focus has been on describing the possibilities and sense of existence of the virtual environments tool, which is virtualenv. A summary of the pros and cons is provided below:

Advantages:

• manages dependencies,
• allows you to isolate the environments of different projects from each other,
• makes work easier,
• allows you to store different versions of the same library on one computer.

Disadvantages:

• you have to wonder where to place the new virtual environment,
• the activation procedure is not very intuitive,
• if virtual environments are randomly distributed throughout the entire file system, it is not possible to list them all.

As you can see, virtualenv is not flawless and with a huge number of simultaneous projects, managing all virtual environments can be problematic. These problems try to remove the second popular tool: virtualenvwrapper.

virtualenvwrapper¶

virtualenvwrapper, as the name suggests, this is a package that wraps the virtual environments tool. It maintains virtualenv functionality, but additionally organizes folders and access to environments, and facilitates the most common operations performed in virtual environments.

virtualenvwrapper - installation¶

To install virtualenvwrapper use thepip tool.

• Windows:

pip install virtualenvwrapper-win

• Linux/Mac:

  • pip install virtualenvwrapper,
  • source virtualenvwrapper.sh - for access to the commands provided by the tool,
  • source ~/.bashrc - reloading the startup file.

Basic operations: creation¶

With virtualenvwrapper installed, we can create a new virtual environment using the command:

mkvirtualenv <enviroment_name>

virtualenvwrapper chooses the location for virtual environments by itself - it is the hidden directory .virtualenvs, located in the home folder.

This location can be configured using the WORKON_HOME environment variable.

Basic operations: activation¶

The virtual environment is activated (same on different operating systems) by command:

workon <enviroment_name>

Basic operations: deactivation¶

Leaving the environment is the same as for virtualenv:

deactivate

Basic operations: dependency installation¶

Dependency installation is exactly the same as in virtualenv - using thepip tool.

virtualenvwrapper - additional operations¶

virtualenvwrapper has several additional commands:

• workon - specifying the command without the environment name as a parameter will print all environments created so far,
• lsvirtualenv - prints all environments created with virtualenvwrapper,
• rmvirtualenv <enviroment_name> removes the virtual environment named <enviroment_name>,
• cpvirtualenv <enviroment_name> <copy_name> copies the environment named <enviroment_name> to the new environment called copy_name.