Install virtualenv with Homebrew, apt, dnf, Nix

Project links

• Homepage
• Repository
• Upstream docs
• Package manager page

Commands and aliases

• virtualenv

Project history

virtualenv grew out of Ian Bicking's earlier workingenv and virtual-python work. Legacy virtualenv documentation describes it as a successor to workingenv and an extension of virtual-python, written by Bicking with sponsorship from The Open Planning Project and later maintained by a developer group under the PyPA umbrella.

The first PyPI files for virtualenv date to September 2007, and the legacy changelog records v0.8 as the initial release. In 2012, Python accepted PEP 405 for built-in virtual environments, explicitly citing the popularity of Ian Bicking's virtualenv as evidence that environment isolation was already a core Python workflow.

The project continued after venv entered the standard library because virtualenv supported more interpreter discovery modes, older Python versions, cross-platform activation scripts, and bundled or seeded installer behavior. The 20.x line was a major modernization of the implementation and seeding model, and recent changelogs show the project still tracking new Python versions and packaging behavior.

Adoption history

virtualenv became a default building block for Python application development, testing, and deployment before Python had a built-in equivalent. PEP 405 described virtual environments as already widely used for dependency management, non-admin package installation, and automated testing across Python versions.

Its adoption is tightly linked to pip and PyPA packaging culture. For years, tutorials, CI systems, tox configurations, and distribution packaging recipes assumed that creating a throwaway virtualenv was the ordinary way to test Python code without contaminating the system interpreter.

How it is used

The common workflow is to run `virtualenv ENV`, activate the environment with the shell-specific activation script, and then install dependencies with pip into that isolated prefix. Modern virtualenv can also select interpreters, delegate some creation paths to venv, and seed environments with packaging tools according to its configured policy.

Even where `python -m venv` is sufficient, virtualenv remains useful when users want faster creation, broader interpreter support, consistent behavior across platforms, or compatibility with older packaging workflows. It is also embedded indirectly in higher-level tools that create disposable environments for testing, building, or application isolation.

Why package nerds care

virtualenv is package-nerd bedrock: it changed Python packaging from a global-machine problem into a per-project directory problem. Much of the later Python tooling stack, including virtualenvwrapper, tox, pipenv, Poetry, nox, and uv-style environment workflows, either builds on the same isolation idea or interoperates with its directory conventions.

Timeline

• 2007: virtualenv was introduced by Ian Bicking.
• 2007-09-14: The earliest virtualenv files currently listed on PyPI were uploaded.
• 2012: PEP 405 proposed Python's standard-library virtual environments, citing virtualenv's established popularity.
• 2020: virtualenv 20.x became the modern line with a rewritten creation and seeding architecture.
• 2026: The active 21.x line continues to track current Python packaging and interpreter changes.

Related projects

• workingenv and virtual-python were direct predecessors. Python's standard-library venv module standardized a subset of the virtual-environment concept. virtualenvwrapper and VirtualFish are shell-oriented managers built around virtualenv-style environments.

Sources

• PEP 405: https://peps.python.org/pep-0405/
• PyPA packaging history: https://www.pypa.io/en/latest/history/
• virtualenv PyPI project: https://pypi.org/project/virtualenv/
• virtualenv changelog: https://virtualenv.pypa.io/en/latest/changelog.html
• virtualenv legacy changelog: https://virtualenv.pypa.io/en/legacy/changes.html
• virtualenv legacy development documentation: https://virtualenv.pypa.io/en/legacy/development.html