VIRTUALENV(1) virtualenv VIRTUALENV(1)

virtualenv - virtualenv 20.35.4 [image: Latest version on PyPI] [image]
https://pypi.org/project/virtualenv/#history[image: PyPI - Implementation] [image] [image: PyPI - Python Version] [image] [image: Documentation status] [image]
https://virtualenv.pypa.io[image: Discord] [image]
https://discord.gg/pypa[image: PyPI - Downloads] [image]
https://pypistats.org/packages/virtualenv[image: PyPI - License] [image]
https://opensource.org/licenses/MIT[image: Open issues] [image]
https://github.com/pypa/virtualenv/issues[image: Open pull requests] [image]
https://github.com/pypa/virtualenv/pulls[image: Package popularity] [image]
https://pypistats.org/packages/virtualenv

virtualenv is a tool to create isolated Python environments.

Since Python 3.3, a subset of it has been integrated into the standard library under the venv module https://docs.python.org/3/library/venv.html. The venv module does not offer all features of this library, to name just a few more prominent:

  • is slower (by not having the app-data seed method),
  • is not as extendable,
  • cannot create virtual environments for arbitrarily installed python versions (and automatically discover these),
  • is not upgrade-able via pip https://pip.pypa.io/en/stable/installing/,
  • does not have as rich programmatic API (describe virtual environments without creating them).

The basic problem being addressed is one of dependencies and versions, and indirectly permissions. Imagine you have an application that needs version 1 of LibFoo, but another application requires version 2. How can you use both these libraries? If you install everything into your host python (e.g. python3.8) it's easy to end up in a situation where two packages have conflicting requirements.

Or more generally, what if you want to install an application and leave it be? If an application works, any change in its libraries or the versions of those libraries can break the application. Also, what if you can't install packages into the global site-packages directory, due to not having permissions to change the host python environment?

In all these cases, virtualenv can help you. It creates an environment that has its own installation directories, that doesn't share libraries with other virtualenv environments (and optionally doesn't access the globally installed libraries either).

With the release of virtualenv 20.22, April 2023, (release note https://virtualenv.pypa.io/en/latest/changelog.html#v20-22-0-2023-04-19) target interpreters are now limited to Python v. 3.7+.

Trying to use an earlier version will normally result in the target interpreter raising a syntax error. This virtualenv tool will then print some details about the exception and abort, ie no explicit warning about trying to use an outdated/incompatible version. It may look like this:

$ virtualenv --discovery pyenv -p python3.6 foo
RuntimeError: failed to query /home/velle/.pyenv/versions/3.6.15/bin/python3.6 with code 1 err: '  File "/home/velle/.virtualenvs/toxrunner/lib/python3.12/site-packages/virtualenv/discovery/py_info.py", line 7
    from __future__ import annotations
    ^
SyntaxError: future feature annotations is not defined

In tox, even if the interpreter is installed and available, the message is (somewhat misleading):

py36: skipped because could not find python interpreter with spec(s): py36

Related projects, that build abstractions on top of virtualenv

Tutorials

Presenting how the package works from within

virtualenv https://pypi.org/project/virtualenv is a CLI tool that needs a Python interpreter to run. If you already have a Python 3.7+ interpreter the best is to use pipx https://pypi.org/project/pipx to install virtualenv into an isolated environment. This has the added benefit that later you'll be able to upgrade virtualenv without affecting other parts of the system.

pipx install virtualenv
virtualenv --help

Alternatively you can install it within the global Python interpreter itself (perhaps as a user package via the --user flag). Be cautious if you are using a python install that is managed by your operating system or another package manager. pip might not coordinate with those tools, and may leave your system in an inconsistent state. Note, if you go down this path you need to ensure pip is new enough per the subsections below:

python -m pip install --user virtualenv
python -m virtualenv --help

Installing virtualenv via a wheel (default with pip) requires an installer that can understand the python-requires tag (see PEP-503 https://www.python.org/dev/peps/pep-0503/), with pip this is version 9.0.0 (released 2016 November). Furthermore, in case you're not installing it via the PyPi you need to be using a mirror that correctly forwards the python-requires tag (notably the OpenStack mirrors don't do this, or older devpi https://github.com/devpi/devpi versions - added with version 4.7.0).

When installing via a source distribution you need an installer that handles the PEP-517 https://www.python.org/dev/peps/pep-0517/ specification. In case of pip this is version 18.0.0 or later (released on 2018 July). If you cannot upgrade your pip to support this you need to ensure that the build requirements from pyproject.toml https://github.com/pypa/virtualenv/blob/main/pyproject.toml#L2 are satisfied before triggering the install.

You can use virtualenv without installing it too. We publish a Python zipapp https://docs.python.org/3/library/zipapp.html, you can just download this from https://bootstrap.pypa.io/virtualenv.pyz and invoke this package with a python interpreter:

python virtualenv.pyz --help

The root level zipapp is always the current latest release. To get the last supported zipapp against a given python minor release use the link https://bootstrap.pypa.io/virtualenv/x.y/virtualenv.pyz, e.g. for the last virtualenv supporting Python 3.11 use https://bootstrap.pypa.io/virtualenv/3.11/virtualenv.pyz.

If you are looking for past version of virtualenv.pyz they are available here:

https://github.com/pypa/get-virtualenv/blob/<virtualenv version>/public/<python version>/virtualenv.pyz?raw=true

Installing an unreleased version is discouraged and should be only done for testing purposes. If you do so you'll need a pip version of at least 18.0.0 and use the following command:

pip install git+https://github.com/pypa/virtualenv.git@main

virtualenv works with the following Python interpreter implementations:

This means virtualenv works on the latest patch version of each of these minor versions. Previous patch versions are supported on a best effort approach.

CPython is shipped in multiple forms, and each OS repackages it, often applying some customization along the way. Therefore we cannot say universally that we support all platforms, but rather specify some we test against. In case of ones not specified here the support is unknown, though likely will work. If you find some cases please open a feature request on our issue tracker.

Note:

  • as of 20.27.0 -- 2024-10-17 -- we no longer support running under Python <=3.7,
  • as of 20.18.0 -- 2023-02-06 -- we no longer support running under Python <=3.6,
  • as of 20.22.0 -- 2023-04-19 -- we no longer support creating environments for Python <=3.6.

In case of macOS we support:

virtualenv env_name
source env_name/bin/activate
.\env_name\Scripts\activate
which python3

Virtualenv has one basic command:

virtualenv venv

Note:

When creating a virtual environment, it's recommended to use a specific Python version, for example, by invoking virtualenv with python3.10 -m virtualenv venv. If you use a generic command like python3 -m virtualenv venv, the created environment will be linked to /usr/bin/python3. This can be problematic because when a new Python version is installed on the system, the /usr/bin/python3 symlink will likely be updated to point to the new version. This will cause the virtual environment to inadvertently use the new Python version, which is often not the desired behavior. Using a specific version ensures that the virtual environment is tied to that exact version, providing stability and predictability.

This will create a python virtual environment of the same version as virtualenv, installed into the subdirectory venv. The command line tool has quite a few of flags that modify the tool's behavior, for a full list make sure to check out CLI flags <#cli-flags>.

The tool works in two phases:

  • Phase 1 discovers a python interpreter to create a virtual environment from (by default this is the same python as the one virtualenv is running from, however we can change this via the p <#p> option).
  • Phase 2 creates a virtual environment at the specified destination (dest <#dest>), this can be broken down into four further sub-steps:
  • create a python that matches the target python interpreter from phase 1,
  • install (bootstrap) seed packages (one or more of pip https://pypi.org/project/pip, setuptools https://pypi.org/project/setuptools, wheel https://pypi.org/project/wheel) in the created virtual environment,
  • install activation scripts into the binary directory of the virtual environment (these will allow end users to activate the virtual environment from various shells).
  • create files that mark the virtual environment as to be ignored by version control systems (currently we support Git only, as Mercurial, Bazaar or SVN do not support ignore files in subdirectories). This step can be skipped with the no-vcs-ignore <#no-vcs-ignore> option.

The python in your new virtualenv is effectively isolated from the python that was used to create it.

Python discovery

The first thing we need to be able to create a virtual environment is a python interpreter. This will describe to the tool what type of virtual environment you would like to create, think of it as: version, architecture, implementation.

virtualenv being a python application has always at least one such available, the one virtualenv itself is using, and as such this is the default discovered element. This means that if you install virtualenv under python 3.8, virtualenv will by default create virtual environments that are also of version 3.8.

Created python virtual environments are usually not self-contained. A complete python packaging is usually made up of thousands of files, so it's not efficient to install the entire python again into a new folder. Instead virtual environments are mere shells, that contain little within themselves, and borrow most from the system python (this is what you installed, when you installed python itself). This does mean that if you upgrade your system python your virtual environments might break, so watch out. The upside of this, referring to the system python, is that creating virtual environments can be fast.

Here we'll describe the built-in mechanism (note this can be extended though by plugins). The CLI flag p <#p> or python <#python> allows you to specify a python specifier for what type of virtual environment you would like, the format is either:

  • a relative/absolute path to a Python interpreter,
  • a specifier identifying the Python implementation, version, architecture in the following format:
{python implementation name}{version}{architecture}

We have the following restrictions:

  • the python implementation is all alphabetic characters (python means any implementation, and if is missing it defaults to python),
  • the version is a dot separated version number optionally followed by t for free-threading,
  • the architecture is either -64 or -32 (missing means any).

For example:

  • python3.8.1 means any python implementation having the version 3.8.1,
  • 3 means any python implementation having the major version 3,
  • 3.13t means any python implementation having the version 3.13 with free threading,
  • cpython3 means a CPython implementation having the version 3,
  • pypy2 means a python interpreter with the PyPy implementation and major version 2.

Given the specifier virtualenv will apply the following strategy to discover/find the system executable:

  • If we're on Windows look into the Windows registry, and check if we see any registered Python implementations that match the specification. This is in line with expectation laid out inside PEP-514 https://www.python.org/dev/peps/pep-0514/
  • If uv-managed https://docs.astral.sh/uv/concepts/python-versions/ Python installations are available, use the first one that matches the specification.
  • Try to discover a matching python executable within the folders enumerated on the PATH environment variable. In this case we'll try to find an executable that has a name roughly similar to the specification (for exact logic, please see the implementation code).

Warning:

As detailed above, virtual environments usually just borrow things from the system Python, they don't actually contain all the data from the system Python. The version of the python executable is hardcoded within the python exe itself. Therefore, if you upgrade your system Python, your virtual environment will still report the version before the upgrade, even though now other than the executable all additional content (standard library, binary libs, etc) are of the new version.

Barring any major incompatibilities (rarely the case) the virtual environment will continue working, but other than the content embedded within the python executable it will behave like the upgraded version. If such a virtual environment python is specified as the target python interpreter, we will create virtual environments that match the new system Python version, not the version reported by the virtual environment.

These are what actually setup the virtual environment, usually as a reference against the system python. virtualenv at the moment has two types of virtual environments:

  • venv - this delegates the creation process towards the venv module, as described in PEP 405 https://www.python.org/dev/peps/pep-0405. This is only available on Python interpreters having version 3.5 or later, and also has the downside that virtualenv must create a process to invoke that module (unless virtualenv is installed in the system python), which can be an expensive operation (especially true on Windows).
  • builtin - this means virtualenv is able to do the creation operation itself (by knowing exactly what files to create and what system files need to be referenced). The creator with name builtin is an alias on the first creator that's of this type (we provide creators for various target environments, that all differ in actual create operations, such as CPython 2 on Windows, PyPy2 on Windows, CPython3 on Posix, PyPy3 on Posix, and so on; for a full list see creator <#creator>).

These will install for you some seed packages (one or more of: pip https://pypi.org/project/pip, setuptools https://pypi.org/project/setuptools, wheel https://pypi.org/project/wheel) that enables you to install additional python packages into the created virtual environment (by invoking pip). Installing setuptools https://pypi.org/project/setuptools is disabled by default on Python 3.12+ environments. wheel https://pypi.org/project/wheel is only installed on Python 3.8, by default. There are two main seed mechanisms available:

  • pip - this method uses the bundled pip with virtualenv to install the seed packages (note, a new child process needs to be created to do this, which can be expensive especially on Windows).
  • app-data - this method uses the user application data directory to create install images. These images are needed to be created only once, and subsequent virtual environments can just link/copy those images into their pure python library path (the site-packages folder). This allows all but the first virtual environment creation to be blazing fast (a pip mechanism takes usually 98% of the virtualenv creation time, so by creating this install image that we can just link into the virtual environments install directory we can achieve speedups of shaving the initial 1 minute and 10 seconds down to just 8 seconds in case of a copy, or 0.8 seconds in case symlinks are available - this is on Windows, Linux/macOS with symlinks this can be as low as 100ms from 3+ seconds). To override the filesystem location of the seed cache, one can use the VIRTUALENV_OVERRIDE_APP_DATA environment variable.

To install a seed package via either pip or app-data method virtualenv needs to acquire a wheel of the target package. These wheels may be acquired from multiple locations as follows:

  • virtualenv ships out of box with a set of embed wheels for all three seed packages (pip https://pypi.org/project/pip, setuptools https://pypi.org/project/setuptools, wheel https://pypi.org/project/wheel). These are packaged together with the virtualenv source files, and only change upon upgrading virtualenv. Different Python versions require different versions of these, and because virtualenv supports a wide range of Python versions, the number of embedded wheels out of box is greater than 3. Whenever newer versions of these embedded packages are released upstream virtualenv project upgrades them, and does a new release. Therefore, upgrading virtualenv periodically will also upgrade the version of the seed packages.
  • However, end users might not be able to upgrade virtualenv at the same speed as we do new releases. Therefore, a user might request to upgrade the list of embedded wheels by invoking virtualenv with the upgrade-embed-wheels <#upgrade-embed-wheels> flag. If the operation is triggered in such a manual way subsequent runs of virtualenv will always use the upgraded embed wheels.

    The operation can trigger automatically too, as a background process upon invocation of virtualenv, if no such upgrade has been performed in the last 14 days. It will only start using automatically upgraded wheel if they have been released for more than 28 days, and the automatic upgrade finished at least an hour ago:

  • the 28 days period should guarantee end users are not pulling in automatically releases that have known bugs within,
  • the one hour period after the automatic upgrade finished is implemented so that continuous integration services do not start using a new embedded versions half way through.

The automatic behavior might be disabled via the no-periodic-update <#no-periodic-update> configuration flag/option. To acquire the release date of a package virtualenv will perform the following:

  • lookup https://pypi.org/pypi/<distribution>/json (primary truth source),
  • save the date the version was first discovered, and wait until 28 days passed.
•
Users can specify a set of local paths containing additional wheels by using the extra-search-dir <#extra-search-dir> command line argument flag.

When searching for a wheel to use virtualenv performs lookup in the following order:

  • embedded wheels,
  • upgraded embedded wheels,
  • extra search dir.

Bundled wheels are all three above together. If neither of the locations contain the requested wheel version or download <#download> option is set will use pip download to load the latest version available from the index server.

Custom distributions often want to use their own set of wheel versions to distribute instead of the one virtualenv releases on PyPi. The reason for this is trying to keep the system versions of those packages in sync with what virtualenv uses. In such cases they should patch the module virtualenv.seed.wheels.embed https://github.com/pypa/virtualenv/tree/main/src/virtualenv/seed/wheels/embed, making sure to provide the function get_embed_wheel (which returns the wheel to use given a distribution/python version). The BUNDLE_FOLDER, BUNDLE_SUPPORT and MAX variables are needed if they want to use virtualenv's test suite to validate.

Furthermore, they might want to disable the periodic update by patching the virtualenv.seed.embed.base_embed.PERIODIC_UPDATE_ON_BY_DEFAULT https://github.com/pypa/virtualenv/tree/main/src/virtualenv/seed/embed/base_embed.py to False, and letting the system update mechanism to handle this. Note in this case the user might still request an upgrade of the embedded wheels by invoking virtualenv via upgrade-embed-wheels <#upgrade-embed-wheels>, but no longer happens automatically, and will not alter the OS provided wheels.

These are activation scripts that will mangle with your shell's settings to ensure that commands from within the python virtual environment take priority over your system paths. For example, if invoking pip from your shell returned the system python's pip before activation, once you do the activation this should refer to the virtual environments pip. Note, though that all we do is change priority; so, if your virtual environments bin/Scripts folder does not contain some executable, this will still resolve to the same executable it would have resolved before the activation.

For a list of shells we provide activators see activators <#activators>. The location of these is right alongside the Python executables: usually Scripts folder on Windows, bin on POSIX. They are called activate, plus an extension that's specific per activator, with no extension for Bash. You can invoke them, usually by source-ing them. The source command might vary by shell - e.g. on Bash it’s source (or .):

source venv/bin/activate

The activate script prepends the virtual environment’s binary folder onto the PATH environment variable. It’s really just convenience for doing so, since you could do the same yourself.

Note that you don't have to activate a virtual environment to use it. You can instead use the full paths to its executables, rather than relying on your shell to resolve them to your virtual environment.

Activator scripts also modify your shell prompt to indicate which environment is currently active, by prepending the environment name (or the name specified by --prompt when initially creating the environment) in brackets, like (venv). You can disable this behavior by setting the environment variable VIRTUAL_ENV_DISABLE_PROMPT to any value. You can also get the environment name via the environment variable VIRTUAL_ENV_PROMPT if you want to customize your prompt, for example.

The scripts also provision a deactivate command that will allow you to undo the operation:

deactivate

Note:

If using Powershell, the activate script is subject to the execution policies http://technet.microsoft.com/en-us/library/dd347641.aspx on the system. By default, Windows 7 and later, the system's execution policy is set to Restricted, meaning no scripts like the activate script are allowed to be executed.

However, that can't stop us from changing that slightly to allow it to be executed. You may relax the system execution policy to allow running of local scripts without verifying the code signature using the following:

Set-ExecutionPolicy RemoteSigned

Since the activate.ps1 script is generated locally for each virtualenv, it is not considered a remote script and can then be executed.

A longer explanation of this can be found within Allison Kaptur's 2013 blog post: There's no magic: virtualenv edition https://www.recurse.com/blog/14-there-is-no-magic-virtualenv-edition explains how virtualenv uses bash and Python and PATH and PYTHONHOME to isolate virtual environments' paths.

At the moment virtualenv offers only CLI level interface. If you want to trigger invocation of Python environments from within Python you should be using the virtualenv.cli_run method; this takes an args argument where you can pass the options the same way you would from the command line. The run will return a session object containing data about the created virtual environment.

from virtualenv import cli_run
cli_run(["venv"])
Create a virtual environment given some command line interface arguments.
  • args -- the command line arguments
  • options -- passing in a VirtualEnvOptions object allows return of the parsed options
  • setup_logging -- True if setup logging handlers, False to use handlers already registered
  • env -- environment variables to use
the session object of the creation (its structure for now is experimental and might change on short notice)
Create a virtualenv session (same as cli_run, but this does not perform the creation). Use this if you just want to query what the virtual environment would look like, but not actually create it.
  • args -- the command line arguments
  • options -- passing in a VirtualEnvOptions object allows return of the parsed options
  • setup_logging -- True if setup logging handlers, False to use handlers already registered
  • env -- environment variables to use
the session object of the creation (its structure for now is experimental and might change on short notice)
Represents a virtual environment creation session.
The verbosity of the run.
Create a virtual environment based on this reference interpreter.
The creator used to build the virtual environment (must be compatible with the interpreter).
The mechanism used to provide the seed packages (pip, setuptools, wheel).
Activators used to generate activations scripts.

virtualenv is primarily a command line application.

It modifies the environment variables in a shell to create an isolated Python environment, so you'll need to have a shell to run it. You can type in virtualenv (name of the application) followed by flags that control its behavior. All options have sensible defaults, and there's one required argument: the name/path of the virtual environment to create. The default values for the command line options can be overridden via the Configuration file or Environment Variables. Environment variables takes priority over the configuration file values (--help will show if a default comes from the environment variable as the help message will end in this case with environment variables or the configuration file).

The options that can be passed to virtualenv, along with their default values and a short description are listed below.

virtualenv [OPTIONS]

Named Arguments
--version '==SUPPRESS==' display the version of the virtualenv package and its location, then exit
--with-traceback False on failure also display the stacktrace internals of virtualenv
--read-only-app-data False use app data folder in read-only mode (write operations will fail with error)
--app-data platform specific application data folder a data folder used as cache by the virtualenv
--reset-app-data False start with empty app data folder
--upgrade-embed-wheels False trigger a manual update of the embedded wheels
verbosity ⇒ verbosity = verbose - quiet, default INFO, mapping => CRITICAL=0, ERROR=1, WARNING=2, INFO=3, DEBUG=4, NOTSET=5
-v, --verbose 2 increase verbosity
-q, --quiet 0 decrease verbosity

core ⇒ options shared across all discovery
--discovery 'builtin' interpreter discovery method; choice of: builtin
-p, --python the python executable virtualenv is installed into interpreter based on what to create environment (path/identifier) - by default use the interpreter where the tool is installed - first found wins
--try-first-with [] try first these interpreters before starting the discovery

core ⇒ options shared across all creator
--creator builtin if exist, else venv create environment via; choice of: cpython3-mac-brew, cpython3-mac-framework, cpython3-posix, cpython3-win, graalpy-posix, graalpy-win, pypy3-posix, pypy3-win, venv
dest directory to create virtualenv at
--clear False remove the destination directory if exist before starting (will overwrite files otherwise)
--no-vcs-ignore False don't create VCS ignore directive in the destination directory
--system-site-packages False give the virtual environment access to the system site-packages dir
--symlinks True try to use symlinks rather than copies, when symlinks are not the default for the platform
--copies, --always-copy False try to use copies rather than symlinks, even when symlinks are the default for the platform

core ⇒ options shared across all seeder
--seeder 'app-data' seed packages install method; choice of: app-data, pip
--no-seed, --without-pip False do not install seed packages
--no-download, --never-download True pass to disable download of the latest pip/setuptools/wheel from PyPI
--download False pass to enable download of the latest pip/setuptools/wheel from PyPI
--extra-search-dir [] a path containing wheels to extend the internal wheel list (can be set 1+ times)
--pip 'bundle' version of pip to install as seed: embed, bundle, none or exact version
--setuptools 'none' version of setuptools to install as seed: embed, bundle, none or exact version
--no-pip False do not install pip
--no-setuptools False do not install setuptools
--no-periodic-update False disable the periodic (once every 14 days) update of the embedded wheels
app-data ⇒ options specific to seeder app-data
--symlink-app-data False symlink the python packages from the app-data folder (requires seed pip>=19.3)

core ⇒ options shared across all activators
--activators comma separated list of activators supported activators to generate - default is all supported; choice of: bash, batch, cshell, fish, nushell, powershell, python, xonsh
--prompt provides an alternative prompt prefix for this environment (value of . means name of the current working directory)

You can control which Python interpreter virtualenv selects using the --python and --try-first-with flags. To avoid confusion, it's best to think of them as the "rule" and the "hint".

``--python <spec>``: The Rule

This flag sets the mandatory requirements for the interpreter. The <spec> can be:

  • A version string (e.g., python3.8, pypy3). virtualenv will search for any interpreter that matches this version.
  • An absolute path (e.g., /usr/bin/python3.8). This is a strict requirement. Only the interpreter at this exact path will be used. If it does not exist or is not a valid interpreter, creation will fail.

``--try-first-with <path>``: The Hint

This flag provides a path to a Python executable to check before virtualenv performs its standard search. This can speed up discovery or help select a specific interpreter when multiple versions exist on your system.

How They Work Together

virtualenv will only use an interpreter from --try-first-with if it satisfies the rule from the --python flag. The --python rule always wins.

Examples:

1.
Hint does not match the rule:
virtualenv --python python3.8 --try-first-with /usr/bin/python3.10 my-env
•
Result: virtualenv first inspects /usr/bin/python3.10. It sees this does not match the python3.8 rule and rejects it. It then proceeds with its normal search to find a python3.8 interpreter elsewhere.
2.
Hint does not match a strict path rule:
virtualenv --python /usr/bin/python3.8 --try-first-with /usr/bin/python3.10 my-env
•
Result: The rule is strictly /usr/bin/python3.8. virtualenv checks the /usr/bin/python3.10 hint, sees the path doesn't match, and rejects it. It then moves on to test /usr/bin/python3.8 and successfully creates the environment.

This approach ensures that the behavior is predictable and that --python remains the definitive source of truth for the user's intent.

Unless VIRTUALENV_CONFIG_FILE is set, virtualenv looks for a standard virtualenv.ini configuration file. The exact location depends on the operating system you're using, as determined by platformdirs https://pypi.org/project/platformdirs application configuration definition. It can be overridden by setting the VIRTUALENV_CONFIG_FILE environment variable. The configuration file location is printed as at the end of the output when --help is passed.

The keys of the settings are derived from the command line option (left strip the - characters, and replace - with _). Where multiple flags are available first found wins (where order is as it shows up under the --help).

For example, --python would be specified as:

[virtualenv]
python = /opt/python-3.8/bin/python

Options that take multiple values, like extra-search-dir can be specified as:

[virtualenv]
extra_search_dir =
    /path/to/dists
    /path/to/other/dists

Default values may be also specified via environment variables. The keys of the settings are derived from the command line option (left strip the - characters, and replace - with _, finally capitalize the name). Where multiple flags are available first found wins (where order is as it shows up under the --help).

For example, to use a custom Python binary, instead of the one virtualenv is run with, you can set the environment variable VIRTUALENV_PYTHON like:

env VIRTUALENV_PYTHON=/opt/python-3.8/bin/python virtualenv

Where the option accepts multiple values, for example for python or extra-search-dir, the values can be separated either by literal newlines or commas. Newlines and commas can not be mixed and if both are present only the newline is used for separating values. Examples for multiple values:

env VIRTUALENV_PYTHON=/opt/python-3.8/bin/python,python3.8 virtualenv
env VIRTUALENV_EXTRA_SEARCH_DIR=/path/to/dists\n/path/to/other/dists virtualenv

The equivalent CLI-flags based invocation for the above examples would be:

virtualenv --python=/opt/python-3.8/bin/python --python=python3.8
virtualenv --extra-search-dir=/path/to/dists --extra-search-dir=/path/to/other/dists

virtualenv allows one to extend the builtin functionality via a plugin system. To add a plugin you need to:

  • write a python file containing the plugin code which follows our expected interface,
  • package it as a python library,
  • install it alongside the virtual environment.

Python discovery

The python discovery mechanism is a component that needs to answer the following question: based on some type of user input give me a Python interpreter on the machine that matches that. The builtin interpreter tries to discover an installed Python interpreter (based on PEP-515 and PATH discovery) on the users machine where the user input is a python specification. An alternative such discovery mechanism for example would be to use the popular pyenv https://github.com/pyenv/pyenv project to discover, and if not present install the requested Python interpreter. Python discovery mechanisms must be registered under key virtualenv.discovery, and the plugin must implement virtualenv.discovery.discover.Discover:

virtualenv.discovery =
     pyenv = virtualenv_pyenv.discovery:PyEnvDiscovery
Discover and provide the requested Python interpreter.

Create a new discovery mechanism.

options -- the parsed options as defined within add_parser_arguments()
Add CLI arguments for this discovery mechanisms.
parser -- the CLI parser
Discovers an interpreter.
the interpreter ready to use for virtual environment creation
the interpreter as returned by run(), cached

Creators are what actually perform the creation of a virtual environment. The builtin virtual environment creators all achieve this by referencing a global install; but would be just as valid for a creator to install a brand new entire python under the target path; or one could add additional creators that can create virtual environments for other python implementations, such as IronPython. They must be registered under and entry point with key virtualenv.create , and the class must implement virtualenv.create.creator.Creator:

virtualenv.create =
     cpython3-posix = virtualenv.create.via_global_ref.builtin.cpython.cpython3:CPython3Posix
A class that given a python Interpreter creates a virtual environment.

Construct a new virtual environment creator.

  • options -- the CLI option as parsed from add_parser_arguments()
  • interpreter -- the interpreter to create virtual environment from
Determine if we can create a virtual environment.
interpreter -- the interpreter in question
None if we can't create, any other object otherwise that will be forwarded to add_parser_arguments()
Add CLI arguments for the creator.
  • parser -- the CLI parser
  • app_data -- the application data folder
  • interpreter -- the interpreter we're asked to create virtual environment for
  • meta -- value as returned by can_create()
Perform the virtual environment creation.
Generate a file indicating that this is not meant to be backed up.
Generate ignore instructions for version control systems.

Seeders are what given a virtual environment will install somehow some seed packages into it. They must be registered under and entry point with key virtualenv.seed , and the class must implement virtualenv.seed.seeder.Seeder:

virtualenv.seed =
     db = virtualenv.seed.fromDb:InstallFromDb
A seeder will install some seed packages into a virtual environment.

Create.

  • options -- the parsed options as defined within add_parser_arguments()
  • enabled -- a flag weather the seeder is enabled or not
Add CLI arguments for this seed mechanisms.
  • parser -- the CLI parser
  • app_data -- the CLI parser
  • interpreter -- the interpreter this virtual environment is based of
Perform the seed operation.
creator -- the creator (based of virtualenv.create.creator.Creator) we used to create this virtual environment

If you want add an activator for a new shell you can do this by implementing a new activator. They must be registered under an entry point with key virtualenv.activate , and the class must implement virtualenv.activation.activator.Activator:

virtualenv.activate =
     bash = virtualenv.activation.bash:BashActivator
Generates activate script for the virtual environment.

Create a new activator generator.

options -- the parsed options as defined within add_parser_arguments()
Check if the activation script is supported in the given interpreter.
interpreter -- the interpreter we need to support
True if supported, False otherwise
Add CLI arguments for this activation script.
  • parser -- the CLI parser
  • interpreter -- the interpreter this virtual environment is based of
Generate activate script for the given creator.
creator -- the creator (based of virtualenv.create.creator.Creator) we used to create this virtual environment

virtualenv is a volunteer maintained open source project and we welcome contributions of all forms. The sections below will help you get started with development, testing, and documentation. We’re pleased that you are interested in working on virtualenv. This document is meant to get you setup to work on virtualenv and to act as a guide and reference to the development setup. If you face any issues during this process, please open an issue https://github.com/pypa/virtualenv/issues/new?title=Trouble+with+development+environment about it on the issue tracker.

virtualenv is a command line application written in Python. To work on it, you'll need:

•
repository:
git clone https://github.com/pypa/virtualenv
cd virtualenv

The easiest way to do this is to generate the development tox environment, and then invoke virtualenv from under the .tox/dev folder

tox -e dev
.tox/dev/bin/virtualenv  # on Linux
.tox/dev/Scripts/virtualenv  # on Windows

virtualenv's tests are written using the pytest https://pypi.org/project/pytest test framework. tox https://pypi.org/project/tox is used to automate the setup and execution of virtualenv's tests.

To run tests locally execute:

tox -e py

This will run the test suite for the same Python version as under which tox is installed. Alternatively you can specify a specific version of python by using the pyNN format, such as: py38, pypy3, etc.

tox has been configured to forward any additional arguments it is given to pytest. This enables the use of pytest's rich CLI https://docs.pytest.org/en/latest/usage.html#specifying-tests-selecting-tests. As an example, you can select tests using the various ways that pytest provides:

# Using markers
tox -e py -- -m "not slow"
# Using keywords
tox -e py -- -k "test_extra"

Some tests require additional dependencies to be run, such is the various shell activators (bash, fish, powershell, etc). These tests will automatically be skipped if these are not present, note however that in CI all tests are run; so even if all tests succeed locally for you, they may still fail in the CI.

virtualenv uses pre-commit https://pypi.org/project/pre-commit for managing linting of the codebase. pre-commit performs various checks on all files in virtualenv and uses tools that help follow a consistent code style within the codebase. To use linters locally, run:

tox -e fix

Note:

Avoid using # noqa comments to suppress linter warnings - wherever possible, warnings should be fixed instead. # noqa comments are reserved for rare cases where the recommended style causes severe readability problems.

virtualenv's documentation is built using Sphinx https://pypi.org/project/Sphinx. The documentation is written in reStructuredText. To build it locally, run:

tox -e docs

The built documentation can be found in the .tox/docs_out folder and may be viewed by opening index.html within that folder.

virtualenv's release schedule is tied to pip and setuptools. We bundle the latest version of these libraries so each time there's a new version of any of these, there will be a new virtualenv release shortly afterwards (we usually wait just a few days to avoid pulling in any broken releases).

Submit pull requests against the main branch, providing a good description of what you're doing and why. You must have legal permission to distribute any code you contribute to virtualenv and it must be available under the MIT License. Provide tests that cover your changes and run the tests locally first. virtualenv supports <#compatibility-requirements> multiple Python versions and operating systems. Any pull request must consider and work on all these platforms.

Pull Requests should be small to facilitate review. Keep them self-contained, and limited in scope. Studies have shown https://www.kessler.de/prd/smartbear/BestPracticesForPeerCodeReview.pdf that review quality falls off as patch size grows. Sometimes this will result in many small PRs to land a single large feature. In particular, pull requests must not be treated as "feature branches", with ongoing development work happening within the PR. Instead, the feature should be broken up into smaller, independent parts which can be reviewed and merged individually.

Additionally, avoid including "cosmetic" changes to code that is unrelated to your change, as these make reviewing the PR more difficult. Examples include re-flowing text in comments or documentation, or addition or removal of blank lines or whitespace within lines. Such changes can be made separately, as a "formatting cleanup" PR, if needed.

All pull requests and merges to 'main' branch are tested using Azure Pipelines https://azure.microsoft.com/en-gb/services/devops/pipelines/ (configured by azure-pipelines.yml file at the root of the repository). You can find the status and results to the CI runs for your PR on GitHub's Web UI for the pull request. You can also find links to the CI services' pages for the specific builds in the form of "Details" links, in case the CI run fails and you wish to view the output.

To trigger CI to run again for a pull request, you can close and open the pull request or submit another change to the pull request. If needed, project maintainers can manually trigger a restart of a job/build.

The changelog.rst file is managed using towncrier https://pypi.org/project/towncrier and all non trivial changes must be accompanied by a news entry. To add an entry to the news file, first you need to have created an issue describing the change you want to make. A Pull Request itself may function as such, but it is preferred to have a dedicated issue (for example, in case the PR ends up rejected due to code quality reasons).

Once you have an issue or pull request, you take the number and you create a file inside of the docs/changelog directory named after that issue number with an extension of:

  • feature.rst,
  • bugfix.rst,
  • doc.rst,
  • removal.rst,
  • misc.rst.

Thus if your issue or PR number is 1234 and this change is fixing a bug, then you would create a file docs/changelog/1234.bugfix.rst. PRs can span multiple categories by creating multiple files (for instance, if you added a feature and deprecated/removed the old feature at the same time, you would create docs/changelog/1234.bugfix.rst and docs/changelog/1234.remove.rst). Likewise if a PR touches multiple issues/PRs you may create a file for each of them with the same contents and towncrier https://pypi.org/project/towncrier will deduplicate them.

The contents of this file are reStructuredText formatted text that will be used as the content of the news file entry. You do not need to reference the issue or PR numbers here as towncrier will automatically add a reference to all of the affected issues when rendering the news file.

In order to maintain a consistent style in the changelog.rst file, it is preferred to keep the news entry to the point, in sentence case, shorter than 120 characters and in an imperative tone -- an entry should complete the sentence This change will …. In rare cases, where one line is not enough, use a summary line in an imperative tone followed by a blank line separating it from a description of the feature/change in one or more paragraphs, each wrapped at 120 characters. Remember that a news entry is meant for end users and should only contain details relevant to an end user.

A trivial change is anything that does not warrant an entry in the news file. Some examples are: code refactors that don't change anything as far as the public is concerned, typo fixes, white space modification, etc. To mark a PR as trivial a contributor simply needs to add a randomly named, empty file to the news/ directory with the extension of .trivial.

If you want to become an official maintainer, start by helping out. As a first step, we welcome you to triage issues on virtualenv's issue tracker. virtualenv maintainers provide triage abilities to contributors once they have been around for some time and contributed positively to the project. This is optional and highly recommended for becoming a virtualenv maintainer. Later, when you think you're ready, get in touch with one of the maintainers and they will initiate a vote among the existing maintainers.

Note:

Upon becoming a maintainer, a person should be given access to various virtualenv-related tooling across multiple platforms. These are noted here for future reference by the maintainers:
  • GitHub Push Access
  • PyPI Publishing Access
  • CI Administration capabilities
  • ReadTheDocs Administration capabilities

Bugfixes - 20.35.4

•
pip to 25.3 from 25.2 (#2989 https://github.com/pypa/virtualenv/issues/2989)

Bugfixes - 20.35.3

•
Accept RuntimeError in test_too_many_open_files, by @esafak https://github.com/esafak (#2935 https://github.com/pypa/virtualenv/issues/2935)

Bugfixes - 20.35.2

•
Revert out changes related to the extraction of the discovery module - by @gaborbernat https://github.com/gaborbernat. (#2978 https://github.com/pypa/virtualenv/issues/2978)

Bugfixes - 20.35.1

Features - 20.35.0

Bugfixes - 20.35.0

Features - 20.34.0

Bugfixes - 20.34.0

Bugfixes - 20.33.1

Features - 20.33.0

•
Added support for Tcl and Tkinter. You're welcome. Contributed by @esafak https://github.com/esafak. (#425 https://github.com/pypa/virtualenv/issues/425)

Bugfixes - 20.33.0

Features - 20.32.0

Bugfixes - 20.32.0

No significant changes.

Bugfixes - 20.31.1

•
Upgrade embedded wheels:

Features - 20.31.0

•
No longer bundle wheel wheels (except on Python 3.8), setuptools includes native bdist_wheel support. Update pip to 25.1. (#2868 https://github.com/pypa/virtualenv/issues/2868)

Bugfixes - 20.31.0

Features - 20.30.0

•
Add support for GraalPy https://github.com/oracle/graalpython. (#2832 https://github.com/pypa/virtualenv/issues/2832)

Bugfixes - 20.30.0

•
Upgrade embedded wheels:
•
setuptools to 78.1.0 from 75.3.2 (#2863 https://github.com/pypa/virtualenv/issues/2863)

Bugfixes - 20.29.3

•
Ignore unreadable directories in PATH. (#2794 https://github.com/pypa/virtualenv/issues/2794)

Bugfixes - 20.29.2

Bugfixes - 20.29.1

•
Fix PyInfo cache incompatibility warnings - by @robsdedude https://github.com/robsdedude. (#2827 https://github.com/pypa/virtualenv/issues/2827)

Features - 20.29.0

•
Add support for selecting free-threaded Python interpreters, e.g., python3.13t. (#2809 https://github.com/pypa/virtualenv/issues/2809)

Bugfixes - 20.29.0

•
Upgrade embedded wheels:
•
setuptools to 75.8.0 from 75.6.0 (#2823 https://github.com/pypa/virtualenv/issues/2823)

Bugfixes - 20.28.1

•
Skip tcsh tests on broken tcsh versions - by @gaborbernat https://github.com/gaborbernat. (#2814 https://github.com/pypa/virtualenv/issues/2814)

Features - 20.28.0

•
Write CACHEDIR.TAG file on creation - by "user:neilramsay. (#2803 https://github.com/pypa/virtualenv/issues/2803)

Bugfixes - 20.27.2

•
Upgrade embedded wheels:
•
setuptools to 75.3.0 from 75.2.0 (#2798 https://github.com/pypa/virtualenv/issues/2798)
•
Upgrade embedded wheels:

Bugfixes - 20.27.1

•
Upgrade embedded wheels:
•
pip to 24.3.1 from 24.2 (#2789 https://github.com/pypa/virtualenv/issues/2789)

Features - 20.27.0

•
Drop 3.7 support as the CI environments no longer allow it running - by @gaborbernat https://github.com/gaborbernat. (#2758 https://github.com/pypa/virtualenv/issues/2758)

Bugfixes - 20.27.0

  • setuptools to 75.2.0 from 75.1.0
  • Removed pip of 24.0
  • Removed setuptools of 68.0.0
  • Removed wheel of 0.42.0
•
by @gaborbernat https://github.com/gaborbernat. (#2783 https://github.com/pypa/virtualenv/issues/2783)
•
Fix zipapp is broken on Windows post distlib 0.3.9 - by @gaborbernat https://github.com/gaborbernat. (#2784 https://github.com/pypa/virtualenv/issues/2784)

Bugfixes - 20.26.6

•
Properly quote string placeholders in activation script templates to mitigate potential command injection - by @y5c4l3 https://github.com/y5c4l3. (#2768 https://github.com/pypa/virtualenv/issues/2768)

Bugfixes - 20.26.5

•
Upgrade embedded wheels: setuptools to 75.1.0 from 74.1.2 - by @gaborbernat https://github.com/gaborbernat. (#2765 https://github.com/pypa/virtualenv/issues/2765)

Bugfixes - 20.26.4

Bugfixes - 20.26.3

•
Upgrade embedded wheels:

Bugfixes - 20.26.2

Bugfixes - 20.26.1

•
fix PATH-based Python discovery on Windows - by @ofek https://github.com/ofek. (#2712 https://github.com/pypa/virtualenv/issues/2712)

Bugfixes - 20.26.0

•
allow builtin discovery to discover specific interpreters (e.g. python3.12) given an unspecific spec (e.g. python3) - by @flying-sheep https://github.com/flying-sheep. (#2709 https://github.com/pypa/virtualenv/issues/2709)

Bugfixes - 20.25.3

•
Python 3.13.0a6 renamed pathmod to parser. (#2702 https://github.com/pypa/virtualenv/issues/2702)

Bugfixes - 20.25.2

•
Upgrade embedded wheels:

Bugfixes - 20.25.1

•
Upgrade embedded wheels:
•
Upgrade embedded wheels:

Misc - 20.25.1

•
#2688 https://github.com/pypa/virtualenv/issues/2688

Features - 20.25.0

•
The tests now pass on the CI with Python 3.13.0a2 - by @hroncok https://github.com/hroncok. (#2673 https://github.com/pypa/virtualenv/issues/2673)

Bugfixes - 20.25.0

•
Upgrade embedded wheels:
•
wheel to 0.41.3 from 0.41.2 (#2665 https://github.com/pypa/virtualenv/issues/2665)
•
Upgrade embedded wheels:

Bugfixes - 20.24.6

Bugfixes - 20.24.5

•
setuptools to 68.2.0 from 68.1.2 (#2642 https://github.com/pypa/virtualenv/issues/2642)

Bugfixes - 20.24.4

•
Upgrade embedded wheels:

Bugfixes - 20.24.3

•
wheel to 0.41.1 from 0.41.0 (#2622 https://github.com/pypa/virtualenv/issues/2622)

Misc - 20.24.3

•
#2610 https://github.com/pypa/virtualenv/issues/2610

Bugfixes - 20.24.2

•
Upgrade embedded wheels:

Bugfixes - 20.24.1

•
Upgrade embedded wheels:
•
pip to 23.2 from 23.1.2 - by @arielkirkwood https://github.com/arielkirkwood (#2611 https://github.com/pypa/virtualenv/issues/2611)

Features - 20.24.0

•
Export the prompt prefix as VIRTUAL_ENV_PROMPT when activating a virtual environment - by @jimporter https://github.com/jimporter. (#2194 https://github.com/pypa/virtualenv/issues/2194)

Bugfixes - 20.24.0

•
setuptools to 68.0.0 from 67.8.0 (#2607 https://github.com/pypa/virtualenv/issues/2607)

Bugfixes - 20.23.1

•
setuptools to 67.8.0 from 67.7.2 (#2588 https://github.com/pypa/virtualenv/issues/2588)

Features - 20.23.0

•
Do not install wheel and setuptools seed packages for Python 3.12+. To restore the old behavior use:
  • for wheel use VIRTUALENV_WHEEL=bundle environment variable or --wheel=bundle CLI flag,
  • for setuptools use VIRTUALENV_SETUPTOOLS=bundle environment variable or --setuptools=bundle CLI flag.

By @chrysle https://github.com/chrysle. (#2487 https://github.com/pypa/virtualenv/issues/2487)

•
3.12 support - by @gaborbernat https://github.com/gaborbernat. (#2558 https://github.com/pypa/virtualenv/issues/2558)

Bugfixes - 20.23.0

Features - 20.22.0

•
Drop support for creating Python <=3.6 (including 2) interpreters. Removed pip of 20.3.4, 21.3.1; wheel of 0.37.1; setuptools of 59.6.0, 44.1.1, 50.3.2- by @gaborbernat https://github.com/gaborbernat. (#2548 https://github.com/pypa/virtualenv/issues/2548)

Bugfixes - 20.21.1

Features - 20.21.0

•
Make closure syntax explicitly starts with {||. (#2512 https://github.com/pypa/virtualenv/issues/2512)

Bugfixes - 20.21.0

Features - 20.20.0

•
Change environment variable existence check in Nushell activation script to not use deprecated command. (#2506 https://github.com/pypa/virtualenv/issues/2506)

Bugfixes - 20.20.0

Features - 20.19.0

•
Allow platformdirs version 3 - by @cdce8p https://github.com/cdce8p. (#2499 https://github.com/pypa/virtualenv/issues/2499)

Features - 20.18.0

•
Drop 3.6 runtime support (can still create 2.7+) - by @gaborbernat https://github.com/gaborbernat. (#2489 https://github.com/pypa/virtualenv/issues/2489)

Bugfixes - 20.18.0

Bugfixes - 20.17.1

Features - 20.17.0

Bugfixes - 20.17.0

Bugfixes - 20.16.7

Features - 20.16.6

•
Drop unneeded shims for PyPy3 directory structure (#2426 https://github.com/pypa/virtualenv/issues/2426)

Bugfixes - 20.16.6

Bugfixes - 20.16.5

•
Do not turn echo off for subsequent commands in batch activators (activate.bat and deactivate.bat) - by @pawelszramowski https://github.com/pawelszramowski. (#2411 https://github.com/pypa/virtualenv/issues/2411)

Bugfixes - 20.16.4

•
Bump embed setuptools to 65.3 - by @gaborbernat https://github.com/gaborbernat. (#2405 https://github.com/pypa/virtualenv/issues/2405)

Bugfixes - 20.16.3

•
Upgrade embedded pip to 22.2.2 from 22.2.1 and setuptools to 63.4.1 from 63.2.0 - by @gaborbernat https://github.com/gaborbernat. (#2395 https://github.com/pypa/virtualenv/issues/2395)

Bugfixes - 20.16.2

•
Bump embedded pip from 22.2 to 22.2.1 - by @gaborbernat https://github.com/gaborbernat. (#2391 https://github.com/pypa/virtualenv/issues/2391)

Features - 20.16.1

•
Update Nushell activation scripts to version 0.67 - by @kubouch https://github.com/kubouch. (#2386 https://github.com/pypa/virtualenv/issues/2386)

Features - 20.16.0

Bugfixes - 20.15.1

Features - 20.15.0

•
Support for Windows embeddable Python package: includes python<VERSION>.zip in the creator sources - by @reksarka https://github.com/reksarka. (#1774 https://github.com/pypa/virtualenv/issues/1774)

Bugfixes - 20.15.0

Features - 20.14.1

•
Support for creating a virtual environment from a Python 2.7 framework on macOS 12 - by @nickhutchinson https://github.com/nickhutchinson. (#2284 https://github.com/pypa/virtualenv/issues/2284)

Bugfixes - 20.14.1

•
Upgrade embedded setuptools to 62.1.0 from 61.0.0 - by @gaborbernat https://github.com/gaborbernat. (#2327 https://github.com/pypa/virtualenv/issues/2327)

Features - 20.14.0

•
Support Nushell activation scripts with nu version 0.60 - by @kubouch https://github.com/kubouch. (#2321 https://github.com/pypa/virtualenv/issues/2321)

Bugfixes - 20.14.0

•
Upgrade embedded setuptools to 61.0.0 from 60.10.0 - by @gaborbernat https://github.com/gaborbernat. (#2322 https://github.com/pypa/virtualenv/issues/2322)

Bugfixes - 20.13.4

Bugfixes - 20.13.3

Bugfixes - 20.13.2

•
Upgrade embedded setuptools to 60.9.3 from 60.6.0 - by @gaborbernat https://github.com/gaborbernat. (#2306 https://github.com/pypa/virtualenv/issues/2306)

Bugfixes - 20.13.1

Features - 20.13.0

•
Add downloaded wheel information in the relevant JSON embed file to prevent additional downloads of the same wheel. - by @mayeut https://github.com/mayeut. (#2268 https://github.com/pypa/virtualenv/issues/2268)

Bugfixes - 20.13.0

Bugfixes - 20.12.1

Features - 20.12.0

•
Sign the python2 exe on Darwin arm64 - by @tmspicer https://github.com/tmspicer. (#2233 https://github.com/pypa/virtualenv/issues/2233)

Bugfixes - 20.12.0

Bugfixes - 20.11.2

•
Fix installation of pinned versions of pip, setuptools & wheel - by @mayeut https://github.com/mayeut. (#2203 https://github.com/pypa/virtualenv/issues/2203)

Bugfixes - 20.11.1

•
Bump embed setuptools to 60.1.1 from 60.1.0 - by @gaborbernat https://github.com/gaborbernat. (#2258 https://github.com/pypa/virtualenv/issues/2258)

Features - 20.11.0

Features - 20.10.0

  • If a "venv" install scheme exists in sysconfig, virtualenv now uses it to create new virtual environments. This allows Python distributors, such as Fedora, to patch/replace the default install scheme without affecting the paths in new virtual environments. A similar technique was proposed to Python, for the venv module https://bugs.python.org/issue45413 - by hroncok (#2208 https://github.com/pypa/virtualenv/issues/2208)
  • The activated virtualenv prompt is now always wrapped in parentheses. This affects venvs created with the --prompt attribute, and matches virtualenv's behavior on par with venv. (#2224 https://github.com/pypa/virtualenv/issues/2224)

Bugfixes - 20.10.0

•
Fix broken prompt set up by activate.bat - by @SiggyBar https://github.com/SiggyBar. (#2225 https://github.com/pypa/virtualenv/issues/2225)

Features - 20.9.0

Bugfixes - 20.9.0

Bugfixes - 20.8.1

Misc - 20.8.1

•
#2189 https://github.com/pypa/virtualenv/issues/2189

  • upgrade embedded setuptools to 58.0.4 from 57.4.0 and pip to 21.2.4 from 21.2.3
  • Add nushell activation script

Bugfixes - 20.7.2

•
Upgrade embedded pip to 21.2.3 from 21.2.2 and wheel to 0.37.0 from 0.36.2 - by @gaborbernat https://github.com/gaborbernat. (#2168 https://github.com/pypa/virtualenv/issues/2168)

Bugfixes - 20.7.1

•
Fix unpacking dictionary items in PythonInfo.install_path (#2165 https://github.com/pypa/virtualenv/issues/2165)

Bugfixes - 20.7.0

•
upgrade embedded pip to 21.2.2 from 21.1.3 and setuptools to 57.4.0 from 57.1.0 - by @gaborbernat https://github.com/gaborbernat (#2159 https://github.com/pypa/virtualenv/issues/2159)

Deprecations and Removals - 20.7.0

•
Removed xonsh activator due to this breaking fairly often the CI and lack of support from those packages maintainers, upstream is encouraged to continue supporting the project as a plugin https://github.com/xonsh/xonsh/issues/3689 - by @gaborbernat https://github.com/gaborbernat. (#2160 https://github.com/pypa/virtualenv/issues/2160)

Features - 20.6.0

•
Support Python interpreters without distutils (fallback to syconfig in these cases) - by @gaborbernat https://github.com/gaborbernat. (#1910 https://github.com/pypa/virtualenv/issues/1910)

Features - 20.5.0

Bugfixes - 20.5.0

•
Bump pip the embedded pip 21.1.3 and setuptools to 57.1.0 - by @gaborbernat https://github.com/gaborbernat. (#2135 https://github.com/pypa/virtualenv/issues/2135)

Deprecations and Removals - 20.5.0

•
Drop python 3.4 support as it has been over 2 years since EOL - by @gaborbernat https://github.com/gaborbernat. (#2141 https://github.com/pypa/virtualenv/issues/2141)

Bugfixes - 20.4.7

•
Upgrade embedded pip to 21.1.2 and setuptools to 57.0.0 - by @gaborbernat https://github.com/gaborbernat. (#2123 https://github.com/pypa/virtualenv/issues/2123)

Bugfixes - 20.4.6

•
Fix site.getsitepackages() broken on python2 on debian - by @freundTech https://github.com/freundTech. (#2105 https://github.com/pypa/virtualenv/issues/2105)

Bugfixes - 20.4.5

Bugfixes - 20.4.4

Bugfixes - 20.4.3

Bugfixes - 20.4.2

•
Running virtualenv --upgrade-embed-wheels crashes - by @gaborbernat https://github.com/gaborbernat. (#2058 https://github.com/pypa/virtualenv/issues/2058)

Bugfixes - 20.4.1

•
Bump embedded pip and setuptools packages to latest upstream supported (21.0.1 and 52.0.0) - by @gaborbernat https://github.com/gaborbernat. (#2060 https://github.com/pypa/virtualenv/issues/2060)

Features - 20.4.0

•
On the programmatic API allow passing in the environment variable dictionary to use, defaults to os.environ if not specified - by @gaborbernat https://github.com/gaborbernat. (#2054 https://github.com/pypa/virtualenv/issues/2054)

Bugfixes - 20.4.0

•
Upgrade embedded setuptools to 51.3.3 from 51.1.2 - by @gaborbernat https://github.com/gaborbernat. (#2055 https://github.com/pypa/virtualenv/issues/2055)

Bugfixes - 20.3.1

Features - 20.3.0

•
The builtin discovery takes now a --try-first-with argument and is first attempted as valid interpreters. One can use this to force discovery of a given python executable when the discovery order/mechanism raises errors - by @gaborbernat https://github.com/gaborbernat. (#2046 https://github.com/pypa/virtualenv/issues/2046)

Bugfixes - 20.3.0

Bugfixes - 20.2.2

•
Bump pip to 20.3.1, setuptools to 51.0.0 and wheel to 0.36.1 - by @gaborbernat https://github.com/gaborbernat. (#2029 https://github.com/pypa/virtualenv/issues/2029)

No significant changes.

Features - 20.2.0

  • Optionally skip VCS ignore directive for entire virtualenv directory, using option no-vcs-ignore <#no-vcs-ignore>, by default False. (#2003 https://github.com/pypa/virtualenv/issues/2003)
  • Add --read-only-app-data option to allow for creation based on an existing app data cache which is non-writable. This may be useful (for example) to produce a docker image where the app-data is pre-populated.
ENV \
    VIRTUALENV_OVERRIDE_APP_DATA=/opt/virtualenv/cache \
    VIRTUALENV_SYMLINK_APP_DATA=1
RUN virtualenv venv && rm -rf venv
ENV VIRTUALENV_READ_ONLY_APP_DATA=1
USER nobody
# this virtualenv has symlinks into the read-only app-data cache
RUN virtualenv /tmp/venv

Patch by @asottile https://github.com/asottile. (#2009 https://github.com/pypa/virtualenv/issues/2009)

Bugfixes - 20.2.0

•
Fix processing of the VIRTUALENV_PYTHON environment variable and make it multi-value as well (separated by comma) - by @pneff https://github.com/pneff. (#1998 https://github.com/pypa/virtualenv/issues/1998)

Features - 20.1.0

•
The python specification can now take one or more values, first found is used to create the virtual environment - by @gaborbernat https://github.com/gaborbernat. (#1995 https://github.com/pypa/virtualenv/issues/1995)

Bugfixes - 20.0.35

Bugfixes - 20.0.34

Bugfixes - 20.0.33

Bugfixes - 20.0.32

Bugfixes - 20.0.31

•
Upgrade embedded pip to 20.2.1, setuptools to 49.6.0 and wheel to 0.35.1 - by @gaborbernat https://github.com/gaborbernat. (#1918 https://github.com/pypa/virtualenv/issues/1918)

Bugfixes - 20.0.30

•
Upgrade pip to 20.2.1 and setuptools to 49.2.1 - by @gaborbernat https://github.com/gaborbernat. (#1915 https://github.com/pypa/virtualenv/issues/1915)

Bugfixes - 20.0.29

•
Upgrade embedded pip from version 20.1.2 to 20.2 - by @gaborbernat https://github.com/gaborbernat. (#1909 https://github.com/pypa/virtualenv/issues/1909)

Bugfixes - 20.0.28

Bugfixes - 20.0.27

Bugfixes - 20.0.26

  • better logging output while running and enable logging on background process call ( _VIRTUALENV_PERIODIC_UPDATE_INLINE may be used to debug behavior inline)
  • fallback to unverified context when querying the PyPi for release date,
  • stop downloading wheels once we reach the embedded version,

by @gaborbernat https://github.com/gaborbernat. (#1883 https://github.com/pypa/virtualenv/issues/1883)

Bugfixes - 20.0.25

•
Fix that when the app-data seeders image creation fails the exception is silently ignored. Avoid two virtual environment creations to step on each others toes by using a lock while creating the base images. By @gaborbernat https://github.com/gaborbernat. (#1869 https://github.com/pypa/virtualenv/issues/1869)

Features - 20.0.24

•
Ensure that the seeded packages do not get too much out of date:
  • add a CLI flag that triggers upgrade of embedded wheels under upgrade-embed-wheels <#upgrade-embed-wheels>
  • periodically (once every 14 days) upgrade the embedded wheels in a background process, and use them if they have been released for more than 28 days (can be disabled via no-periodic-update <#no-periodic-update>)

More details under Wheels <#wheels> - by @gaborbernat https://github.com/gaborbernat. (#1821 https://github.com/pypa/virtualenv/issues/1821)

•
Upgrade embed wheel content:
  • ship wheels for Python 3.9 and 3.10
  • upgrade setuptools for Python 3.5+ from 47.1.1 to 47.3.1

by @gaborbernat https://github.com/gaborbernat. (#1841 https://github.com/pypa/virtualenv/issues/1841)

•
Display the installed seed package versions in the final summary output, for example:
created virtual environment CPython3.8.3.final.0-64 in 350ms
  creator CPython3Posix(dest=/x, clear=True, global=False)
  seeder FromAppData(download=False, pip=bundle, setuptools=bundle, wheel=bundle, via=copy, app_data_dir=/y/virtualenv)
    added seed packages: pip==20.1.1, setuptools==47.3.1, wheel==0.34.2

by @gaborbernat https://github.com/gaborbernat. (#1864 https://github.com/pypa/virtualenv/issues/1864)

Bugfixes - 20.0.24

Improved Documentation - 20.0.24

Bugfixes - 20.0.23

•
Fix typo in setup.cfg - by @RowdyHowell https://github.com/RowdyHowell. (#1857 https://github.com/pypa/virtualenv/issues/1857)

Bugfixes - 20.0.22

Features - 20.0.21

•
Generate ignore file for version control systems to avoid tracking virtual environments by default. Users should remove these files if still want to track. For now we support only git by @gaborbernat https://github.com/gaborbernat. (#1806 https://github.com/pypa/virtualenv/issues/1806)

Bugfixes - 20.0.21

Bugfixes - 20.0.20

Bugfixes - 20.0.19

Bugfixes - 20.0.18

•
Importing setuptools before cli_run could cause our python information query to fail due to setuptools patching distutils.dist.Distribution - by @gaborbernat https://github.com/gaborbernat. (#1771 https://github.com/pypa/virtualenv/issues/1771)

Features - 20.0.17

•
Extend environment variables checked for configuration to also check aliases (e.g. setting either VIRTUALENV_COPIES or VIRTUALENV_ALWAYS_COPY will work) - by @gaborbernat https://github.com/gaborbernat. (#1763 https://github.com/pypa/virtualenv/issues/1763)

Bugfixes - 20.0.16

•
Allow seed wheel files inside the extra-search-dir <#extra-search-dir> folders that do not have Requires-Python metadata specified, these are considered compatible with all python versions - by @gaborbernat https://github.com/gaborbernat. (#1757 https://github.com/pypa/virtualenv/issues/1757)

Features - 20.0.15

•
Upgrade embedded setuptools to 46.1.3 from 46.1.1 - by @gaborbernat https://github.com/gaborbernat. (#1752 https://github.com/pypa/virtualenv/issues/1752)

Features - 20.0.14

Bugfixes - 20.0.14

•
Fix discovery of interpreter by name from PATH that does not match a spec format - by @gaborbernat https://github.com/gaborbernat. (#1746 https://github.com/pypa/virtualenv/issues/1746)

Bugfixes - 20.0.13

Bugfixes - 20.0.12

•
Fix relative path discovery of interpreters - by @gaborbernat https://github.com/gaborbernat. (#1734 https://github.com/pypa/virtualenv/issues/1734)

Features - 20.0.11

•
Improve error message when the host python does not satisfy invariants needed to create virtual environments (now we print which host files are incompatible/missing and for which creators when no supported creator can be matched, however we found creators that can describe the given Python interpreter - will still print no supported creator for Jython, however print exactly what host files do not allow creation of virtual environments in case of CPython/PyPy) - by @gaborbernat https://github.com/gaborbernat. (#1716 https://github.com/pypa/virtualenv/issues/1716)

Bugfixes - 20.0.11

Improved Documentation - 20.0.11

•
supports <#compatibility-requirements> details now explicitly what Python installations we support - by @gaborbernat https://github.com/gaborbernat. (#1714 https://github.com/pypa/virtualenv/issues/1714)

Bugfixes - 20.0.10

Improved Documentation - 20.0.10

Bugfixes - 20.0.9

Bugfixes - 20.0.8

Bugfixes - 20.0.7

•
Disable distutils fixup for python 3 until pypa/pip #7778 https://github.com/pypa/pip/issues/7778 is fixed and released - by @gaborbernat https://github.com/gaborbernat. (#1669 https://github.com/pypa/virtualenv/issues/1669)

Bugfixes - 20.0.6

  • the application data folder is now controllable via app-data <#app-data>,
  • clear-app-data now cleans the entire application data folder, not just the app-data seeder path,
  • check if the application data path passed in does not exist or is read-only, and fallback to a temporary directory,
  • temporary directory application data is automatically cleaned up at the end of execution,
  • symlink-app-data <#symlink-app-data> is always False when the application data is temporary

by @gaborbernat https://github.com/gaborbernat. (#1640 https://github.com/pypa/virtualenv/issues/1640)

Features - 20.0.5

Bugfixes - 20.0.5

Features - 20.0.4

•
When aliasing interpreters, use relative symlinks - by @asottile https://github.com/asottile. (#1596 https://github.com/pypa/virtualenv/issues/1596)

Bugfixes - 20.0.4

Bugfixes - 20.0.3

Improved Documentation - 20.0.3

•
Document a programmatic API as from virtualenv import cli_run under Programmatic API <#programmatic-api> - by @gaborbernat https://github.com/gaborbernat. (#1585 https://github.com/pypa/virtualenv/issues/1585)

Features - 20.0.2

Bugfixes - 20.0.2

  • do not fail if there are executables that fail to query (e.g. for not having execute access to it) on the PATH,
  • beside the prefix folder also try with the platform dependent binary folder within that,

by @gaborbernat https://github.com/gaborbernat. (#1545 https://github.com/pypa/virtualenv/issues/1545)

  • When copying (either files or trees) do not copy the permission bits, last access time, last modification time, and flags as access to these might be forbidden (for example in case of the macOs Framework Python) and these are not needed for the user to use the virtual environment - by @gaborbernat https://github.com/gaborbernat. (#1561 https://github.com/pypa/virtualenv/issues/1561)
  • While discovering a python executables interpreters that cannot be queried are now displayed with info level rather than warning, so now they're no longer shown by default (these can be just executables to which we don't have access or that are broken, don't warn if it's not the target Python we want) - by @gaborbernat https://github.com/gaborbernat. (#1574 https://github.com/pypa/virtualenv/issues/1574)
  • The app-data seeder <#seeder> no longer symlinks the packages on UNIX and copies on Windows. Instead by default always copies, however now has the symlink-app-data <#symlink-app-data> flag allowing users to request this less robust but faster method - by @gaborbernat https://github.com/gaborbernat. (#1575 https://github.com/pypa/virtualenv/issues/1575)

Improved Documentation - 20.0.2

Features - 20.0.1

•
upgrade embedded setuptools to 45.2.0 from 45.1.0 for Python 3.4+ - by @gaborbernat https://github.com/gaborbernat. (#1554 https://github.com/pypa/virtualenv/issues/1554)

Bugfixes - 20.0.1

Improved Documentation - 20.0.0.

•
Fixes typos, repeated words and inconsistent heading spacing. Rephrase parts of the development documentation and CLI documentation. Expands shorthands like env var and config to their full forms. Uses descriptions from respective documentation, for projects listed in related links - by @pradyunsg https://github.com/pradyunsg. (#1540 https://github.com/pypa/virtualenv/issues/1540)

Features - 20.0.0b2

•
Improve base executable discovery mechanism:
  • print at debug level why we refuse some candidates,
  • when no candidates match exactly, instead of hard failing fallback to the closest match where the priority of matching attributes is: python implementation, major version, minor version, architecture, patch version, release level and serial (this is to facilitate things to still work when the OS upgrade replace/upgrades the system python with a never version, than what the virtualenv host python was created with),
  • always resolve system_executable information during the interpreter discovery, and the discovered environment is the system interpreter instead of the venv/virtualenv (this happened before lazily the first time we accessed, and caused reporting that the created virtual environment is of type of the virtualenv host python version, instead of the system pythons version - these two can differ if the OS upgraded the system python underneath and the virtualenv host was created via copy),

by @gaborbernat https://github.com/gaborbernat. (#1515 https://github.com/pypa/virtualenv/issues/1515)

Bugfixes - 20.0.0b2

  • no longer shows accepted interpreters information (as the last proposed one is always the accepted one),
  • do not display the str_spec attribute for PythonSpec as these can be deduced from the other attributes,
  • for the app-data seeder do not show the type of lock, only the path to the app data directory,

By @gaborbernat https://github.com/gaborbernat. (#1510 https://github.com/pypa/virtualenv/issues/1510)

Improved Documentation - 20.0.0b2

Warning:

The current virtualenv is the second iteration of implementation. From version 0.8 all the way to 16.7.9 we numbered the first iteration. Version 20.0.0b1 is a complete rewrite of the package, and as such this release history starts from there. The old changelog is still available in the legacy branch documentation https://virtualenv.pypa.io/en/legacy/changes.html.

Author name not set

2007-2025, PyPA, PyPA

November 1, 2025 20.35