Install Virtualenv Ubuntu

Introduction to Virtualenv

It is a tool to make separate Python environments. Since the 3.3 version of Python, a subset of virtualenv has been developed into the standard library upon the module, i.e., venv. This module doesn't provide every aspect of this library for naming, only some more prominent ones.

• It is not as extendable.
• It is slower.
• It can't make virtual environments for installed python releases arbitrarily (and discover these automatically).
• It is not upgradeable by pip.
• It doesn't have as strong programmatic API (define virtual environments without making them).

The common problem being described is one of the versions, dependencies, and permissions indirectly. Suppose we have software that requires LibFoo version 1, but another software needs 2 version. How can we use these libraries? If we install everything into our host python (for example, python 3.8), it is easy to end up in a condition in which two packages have clashing requirements.

Or what if we wish to install software and leave it be? If the software works, any modification in its library or those library versions can break the software. What if we can also not install packages into the global directory, i.e., site-packages, because of not having permission to modify the host Python environment?

In each of these situations, virtualenv can aid us. It makes an environment that includes its installation directories that do not share libraries with any other virtualenv environment (and do not access the installed libraries globally).

Virtualenv has a common command:

It will establish a Python virtual environment of a similar release as virtualenv, installed into the venv subdirectory. The command line tool has some flags that change the behavior of the tool. For a complete list, make sure to inspect CLI flags.

These tools work in two different phases:

• Phase 1 recognizes a Python interpreter for creating the virtual environment from (it is a similar python by default as the one virtualenv is executing from; however, we can modify it by the option, i.e., p).
• Phase 2 establishes a virtual environment at the described (dest) destination; it can be broken down into four different sub-steps:
  • establish a python that can match the destination Python interpreter through phase 1,
  • Bootstrap (install) seed packages (multiple wheel, setuptools, and pip) in the made virtual environment,
  • establish files that highlight the virtual environment to be avoided by version control systems. It can be skipped using the option, i.e., no-vcs-ignore.
  • download activation scripts into a binary directory of the virtual environment (it will permit end users for activating the virtual environment from many shells).

Note: In our virtualenv, the python is isolated effectively from the python that was utilized to establish it.

Discovery of Python

The python interpreter is the initial thing that we should have to be able to make a virtual environment. It will tell the tool what kind of virtual environment we would like to establish; think of it as implementation, architecture, or version. If we install virtualenv under the 3.8 release of Python, virtualenv will make virtual environments by default that are also of release 3.8.

Usually, established python virtual environments are not self-contained. A full python packaging is composed of several files, so it is not able to install the whole python again into a fresh folder. Rather virtual environments are simple shells that include little in themselves and borrow almost everything from the system python. It does mean that if we upgrade our system to python, our virtual environments may break, so we need to be careful. Referring to the python system, the upside of it is that establishing virtual environments can be quick.

Here we will define the built-in mechanism. The CLI flag python or p permits us to define a python specifier for what kind of virtual environment we would like; that type is either:

• a specifier recognizing the Python implementation, architecture, or version in the below format:

• an absolute/relative path to the Python interpreter

We have the below limitations:

• The version is a dot isolated version number.
• The Python implementation is every alphabetic character.
• The architecture is either -32 or -64. For example:
  • python3.8.1 defines any Python implementation as having the 3.8.1 version.
  • 3 defines any Python implementation having the 3 major version.
  • cpython3 defines a CPython implementation having the 3 version.
  • pypy2 defines a python interpreter along with the major version 2 and PyPy implementation.

Given the virtualenv specifier will use the below strategy to find/discover the system executable:

• On Windows, if we are looking into the Windows registry and inspect if we see the registered Python implementations that are the same as a specification. It is inside the line, along with the expectations laid down in PEP-514.
• Try to find the same Python executable inside the folders calculated on the PATH environment variable.

Creators

Creators are what configure the virtual environment as a reference as opposed to the system python. At the moment, virtualenv has two different types of virtual environments:

• builtin: It means virtualenv can do the operation creation itself (by exactly knowing what files to make and what system files require to be referenced). With a builtin name, the creator is an alias on the initial creator that is of this type.
• venv: It associates the creation process to the venv module, as defined in PEP 405. It is only present on Python interpreters having 3.5 or later versions and also includes the downside that virtualenv should make a process for invoking that module.

Seeders

Seeders will install a few seed packages for us (one or more of wheel, setuptools, pip) that enable us to install extra Python packages inside the created virtual environment. There are two different primary seed mechanisms present:

• pip: This mechanism applies the bundled pip along with virtualenv for installing the seed packages.
  Important: A new child process requires to be made to do it, which can be costly, especially in Windows.
• app-data: This mechanism applies a directory of the user application data to make install images. The images are required to be made once only, and successive virtual environments can just copy/link the images in their python library path. It permits all but the initial virtual environment establishment to be blazing quickly. One can use the environment variable, i.e., VIRTUALENV_OVERRIDE_APP_DATA, to override the seed cache filesystem location.

Wheels

For installing a seed package by either app-data or pip mechanism, virtualenv requires to inherit a wheel of the destination package. The wheels may be inherited from more than one location:

• virtualenv moves out of the box with a group of embedded wheels for each of three seed packages (wheel, setuptools, pip). These are packaged with the virtualenv source file and just modified under upgrading virtualenv. Different versions of Python need different releases of these, and due to virtualenv supports a huge variety of Python versions, several embedded wheels are greater than 3. If new releases of these embedded packages are published, the upstream project, i.e., virtualenv, upgrades them and publishes a new release. Hence, periodically upgrading virtualenv will upgrade the seed package versions.
• Although, end users may not be capable of upgrading virtualenv at a similar speed. Hence, a user may request for upgrading the embedded wheel list by conjuring virtualenv with the flag, i.e., upgrade-embed-wheels. If the operation is encountered in such a manual style, successive executions of virtualenv will always apply the upgraded embed wheels.
  If no such upgrade has been implemented in the last 14 days, the operation can also encounter as a background process under virtualenv invocation automatically. It will only begin using upgraded wheels automatically if they have been published for 28+ days and the upgrade was completed at least one hour ago:
  • The 28 days time should ensure end users aren't automatically pulling in versions that have known bugs inside,
  • An hour time after the upgrade completed is implemented, so the integration services don't start with a new embedded version when half finished.

The automatic behaviour may be deactivated by the no-periodic-update configuration option/flag. To inherit the release date of any package, virtualenv will implement the below:

• lookup https://pypi.org/pypi/<distribution>/json
• save the date the release was first found and wait for 28 days.

Users can describe a group of local paths including extra wheels with the command line flag, i.e., extra-search-dir.

When finding a wheel to apply, virtualenv performs a lookup inside the below order:

• extra-search-dir
• upgraded embedded wheels
• embedded wheels

Bundled wheels are each 3 above together. If the locations don't include the requested wheel release or the download flag is set will apply pip download for loading the latest release available in the index server.

Distribution Embed Wheels

Sometimes, custom distributions want to use their group of wheel versions for distributing rather than a single virtualenv version on PyPi. The cause for it is attempting to keep the system releases of those packages within sync with what virtualenv applies. In such situations, they should patch the virtualenv.seed.wheels.embed module, ensuring to offer the get_embed_wheel function. The MAX, BUNDLE_SUPPORT, and BUNDLE_FOLDER variables are required if they wish to use the test suite of virtualenv to validate.

Activators

Activation scripts are available, and these will Mangal with the settings of our shell to make sure that commands from inside the Python virtual environment take preference over our system paths. For instance, if invoking pip through our shell given the pip of the system python before activation, when we do the activation, it should refer to the pip virtual environment.

Programmatic API

Virtualenv provides a CLI level interface only at the moment. If we wish to encounter python environment invocation from inside python, we should be utilized the method, i.e., virtualenv.cli_run; it takes an argument, i.e., args, where we can pass the options the similar way you would from the command line.

There are some arguments of the command line interface to establish a virtual environment:

Parameters

• args- The arguments of the command line
• options- passing in an object, i.e., VirtualEnvOptions, permits the parsed option to return
• setup_logging- False for using handlers registered already and True if configuring login handlers
• env- environment variable to apply

Returns

Creation session object

Establish a virtualenv session (similar to cli_run, but it doesn't implement the creation). Use it if we wish to know what the virtual environment will look like but not establish it:

Parameters

• args- The arguments of the command line
• options- passing in an object, i.e., VirtualEnvOptions, permits the parsed option to return
• setup_logging- False for using handlers registered already and True if configuring login handlers
• env- environment variable to apply

Returns

Creation session object

Illustrates the creation session of a virtual environment

• property verbosity
  he run verbosity
• property interpreter
  Establish a virtual environment according to this preferred interpreter
• property creator
  A creator used for building the virtual environment
• property seeder
  A mechanism used for offering the seed packages (wheel, setuptools, pip)
• property activators
  The activators used for generating activation scripts

CLI interface

CLI flags

Primarily, virtualenv is a command-line application. It changes the environment variable inside a shell to establish a separate Python environment, so we will need to have any shell to execute it. We can type inside virtualenv (application's name) pursued by flags that can control its nature.

Every option contains sensible defaults, and there is one needed argument, then the path/name of the virtual environment to establish. The command line option's default values can be overridden by the Environment Variables or Configuration file. Environment variables take preference over the values of the configuration file.

The options that can be acknowledged to virtualenv, along with a short description and their default values, are mentioned as follows:

virtualenv [OPTIONS]

• --version
  It shows the virtualenv package version and its location and exit.
• --read-only-app-data
  It uses the folder of app data in the read-only mode (write tasks will fail with a bug).
• --with-traceback
  It shows the stacktrace virtualenv internals also on failure.
• --app-data
  It is a data folder utilized as a cache through the virtualenv.
• --upgrade-embed-wheels
  It encounters a manual embedded wheels update.
• --reset-app-data
  It begins with a blank app data folder.
• --verbose, -v
  It increases verbosity.
• --quiet, -q
  It decreases verbosity.

Creator options

• creator
  It can create an environment by choice of venv, pypy3-win, pypy3-posix, pypy2-win, pypy2-posix, cpython3-win, cpython3-posix, cpython3-mac-framework, cpython2-win, cpython2-posix, cpython2-mac-framework, cpython2-mac-arm-framework.
• --clear
  It removes the target directory if available before starting (otherwise, it will overwrite the files).
• dest
  It is a directory to establish virtualenv at.
• --no-vcs-ignore
  It does not establish VCS ignore directive within the target directory.
• --symlinks
  When symlinks aren't the default for the environment, it tries to apply symlinks instead of copies.
• --system-site-packages
  It provides access to the virtual environment to the system site-packages dir.
• --always-copy, --copies
• Even if symlinks are the default for the environment, it tries to apply copies instead of symlinks.

Seeder Options

• --seeder
  The method to install seed packages. Choice of: pip, app-data.
• --without-pip, --no-seed
  It doesn't install seed packages.
• --download
  It passes to activate the download for the current wheel/setuptools/pip from PyPI.
• --never-download, --no-download
  It passes to deactivate the download for the current wheel/setuptools/pip from PyPI.
• --extra-search-dir
  It is a path having wheels for extending the internal wheel list.
• --pip
  It is a release of the pip for installing as seed: exact, embed, or bundle version.
• --setuptools
  It is a release of setuptools for installing as seed: exact, bundle, or embed version.
• --wheel
  It is a release of the wheel for installing as seed: exact, bundle, or embed version.
• --no-pip
  It doesn't install pip.
• --no-setuptools
  It doesn't install setuptools.
• --no-wheel
  It doesn't install the wheel.
• --no-periodic-update
  It can deactivate the embedded wheel the with periodic update.
• --symlinks-app-data
  It can symlink the python packages through the app-data folder.

Activators Options

• --activators
  These are the activators to produce. The default is supported; choice of python, powershell, nushell, fish, cshell, batch, bash.
• --prompt
  It offers an alternative prefix of prompt for this environment ("." value means the current working directory name).

Defaults

Environment Variables

Also, default values may be specified by environment variables. The setting keys are acquired from the command line option, where more than one flag is present first detected wins.

Configuration file

Virtualenv finds a standard configuration file, i.e., ini. The same location relies on the operating system we are using as defined by platformdirs definition of the application configuration. The location of the configuration file is mentioned at the completion of the output when the --help option is passed. The setting keys are acquired from the command line option, where more than one flag is present first detected wins.

Extend functionality

Virtualenv permits one for extending the builtin functionality by a plugin system. For adding a plugin, we need to:

• specify a python file having the plugin code which pursues our desired interface,
• install it with the virtual environment,
• package it as any python library.

Installing virtualenv in Ubuntu

Virtualenv is an open-source and free tool to create separate Python virtual environments. It's widely used by Python developers and programmers to test their distinct application versions with ease. All virtual environments have their Python library (which is the same as the binary version that was used for creating this environment) and can have their independent group of installed Python packages in their site directories. Basic installation tools like pip and setuptools to operate as expected using virtual environments.

Step 1: Prerequisites

• We should have an active Ubuntu Server.
• We should have root or sudo access to execute privileged commands.
• We should have apt-get or apt utility available in our system.

Step 2: Update Our Server

First, we need to update every package in our system by running the sudo apt update command. It will sync our system packages with the currently available versions through the Ubuntu repository.

If any system packages are required to be upgraded, we can run the sudo apt upgrade command.

Step 3: Installing Python3

We will install the Python3 package with the sudo apt install python3 command in this step. It will download and install this package with each of its dependencies.

Step 4: Installing pip3

We will install the current release of the python package manager with the sudo apt install python-pip3 command because we require to have pip3 to get virtualenv.

Step 5: Installing virtualenv

In this step, we will install virtualenv with the pip3 install virtualenv command. If we are using a previous version of pip, we need to run the pip install virtualenv command. The command is shown in the below screenshot:

Step 6: Checking Version

We need to run the virtualenv --version command to check the virtualenv installation.

Step 7: Establishing a Virtual Environment

We can establish a virtual environment with the virtualenv venv command after the installation process.

Step 8: Activating or Deactivating Environment

A virtual environment can be activated or deactivated with a script in its binary directory when it is established. We need to run the source venv/bin/activate command for activating a virtual environment.

We can run the deactivate command for deactivating the virtual environment.