SoFunction
Updated on 2024-11-13

A detailed explanation of how to manage multiple Python versions and virtual environments

Multiple Python versions: Install different Python versions on the same machine, e.g. 2.7 and 3.4.

Virtual environments: stand-alone environments that can either install a specific version of Python at the same time, or any project-specific package without affecting any other project.

Here, we will describe three different tools for using them and when each is needed. Let's explore the following use cases:

  • venv / pyvenv
  • pyenv
  • pyenv-virtualenv

If you use a single version of Python such as version 3.3+ and want to manage different virtual environments, then venv is what you need.

If you want to use multiple 3.3+ versions of Python, with or without a virtual environment, then use pyenv.

If you still want to use Python 2, then this pyenv-virtualenv is a good choice.

VENV

Python version 3.3+ includes the venv package. It is ideal for creating lightweight virtual environments.

Until Python 3.6, a called script pyvenv was also included in venv as a wrapper, but this has been deprecated. It will be completely removed in Python 3.8. The exact same functionality is available when using venv, and all existing documentation should be updated.

venv is used to create a new environment with the terminal command.

$ python3 -m venv directory-name-to-create

Activation:

$ source name-given/bin/activate

Deactivate by:

$ deactivate

Runs if you need to completely remove the environment after deactivating it:

$ rm -r name-given

By default, the environment it creates is the version of Python you are currently using. If you are writing documentation and want your readers to use the correct version of Python, you can specify the major version number and the minor version number in the command, as shown below:

$ python3.6 -m venv example-three-six

If the reader is using a version other than 3.6, the command will not succeed and will be indicated in its error message. However, any patched version (e.g. 3.6.4) will work.

When the environment is active, any package can be installed to it normally via pip. By default, the newly created environment does not contain any packages already installed on the machine. This is because pip it will not necessarily be installed on the machine itself. It is recommended to use first, upgrade pip to the latest version pip install --upgrade pip.

Projects usually have a file that specifies their dependencies. This allows all packages to be quickly installed into the newly created virtual environment using the shortcut command pip install -r command. They exist only in the virtual environment. It will be unavailable when deactivated, but will remain unchanged when reactivated.

If you don't need to use another version of Python itself, then you only need to create isolated, project-specific virtual environments.

pyenv

If you wish to use multiple versions of Python on a single computer, pyenv is the go-to tool for installing and switching between versions. This is not to be confused with the depreciated pyenv script mentioned earlier. It is not bundled with Python and must be installed separately.

The pyenv documentation gives a good description of how it works, so we will briefly describe how to use it here. First, we need to install it. If using Mac OS X, you can perform this using Homebrew, or consider other installation options.

$ brew update
$ brew install pyenv

Next, add the following to the bottom of the shell script to allow pyenv to change the version automatically:

eval "$(pyenv init -)"

Open the shell script you are using and copy and paste the line above via $ ~/.zshrc, $ ~/.bashrc or $ ~/.bash_profile.

Running pyenv version will show which Python versions are currently installed, with a * next to the currently used version. pyenv version shows this directly, and python --version can be used to verify this.

To install an additional version, such as 3.4.0, simply use pyenv install 3.4.0.

pyenv determines which version of Python to use in four ways, prioritized as follows.

  1. The PYENV_VERSION environment variable (if specified). You can use this pyenv shell command to set this environment variable in the current shell session.
  2. Application-specific .python version files in the current directory, if they exist. You can use the pyenv local command to modify the .python version file in the current directory.
  3. Find (if any) the first .python version of the file by searching each parent directory until you find the root of the filesystem.
  4. Global version file. You can modify this file with the pyenv global command. If the global version file does not exist, pyenv assumes that you want to use "system" Python (in other words, whichever version is running if pyenv is not in your path).

When setting up a new project with Python 3.6.4, pyenv local 3.6.4 will run in its root directory. This will set the version and create a .python-version file so that other contributors' machines can pick it up.

A full description of the pyenv command can be bookmarked.

pyenv and venv

When using Python 3.3+, we now know how to install and switch between different versions of Python and how to create new virtual environments.

For example, let's say we're building a project that uses Python 3.4.

First, we can use setup local version pyenv local 3.4.0.

If we then run python3 -m venv example-project the new virtual environment will example-project be set up using our locally enabled Python 3.4.0.

We activate the use of source example-project/bin/activate and can start working.

Next, we can optionally record what the collaborator should have used python3.4 -m venv <name>. This means that even if the collaborator doesn't use pyenv for that python3.4 command, if their Python version isn't the major and minor versions (3 and 4) that we want, it will still error out.

If we think that any version greater than 3.4 is acceptable, then we can also choose to use python3 instead of python3.4, just as collaborators use 3.6, otherwise they too would receive an error. This is a project-specific decision.

pyenv-virtualenv

pyenv can be used to install Python versions 2 and 3. However, as we have seen, venv is limited to Python versions greater than 3.3.

pyenv-virtualenv is a tool for creating virtual environments that integrate with pyenv for all Python versions. If possible, it is still recommended to use the official Python venv. But, for example, if you are creating a virtual environment based on 2.7.13, then this is a compliment to pyenv.

If you already use it, it also works for Anaconda and Miniconda conda environments. virtualenv also exists a tool called. It's not covered here, but it ends up being linked.

Install pyenv, which can next be installed using Homebrew (or an alternative) as shown below:

$ brew install pyenv-virtualenv

Next add the following to your .zshrc,, .bashrc or .bash_profile (depending on the shell you are using) at the bottom:

eval "$(pyenv init -)"
eval "$(pyenv virtualenv-init -)"

This allows pyenv to automatically activate and deactivate the environment when moving directories.

To create a new virtual environment, use:

$ pyenv virtualenv <version> <name-to-give-it>
// for example
$ pyenv virtualenv 2.7.10 my-virtual-env-2.7.10

Existing environments can be listed:

$ pyenv virtualenvs

Activate/deactivate:

$ pyenv activate <name>
$ pyenv deactivate

At the time of writing activate, prompt changing will be removed from future release will display a usage warning. This is expected and refers only to what (env-name) displays in the shell, not to the use of the activate command itself.

The installation requirements work as described below for venv. unlike in venv an rm -r command is not required to remove an environment, an uninstall command exists.

This is the whole content of this article.