Install virtualenvwrapper with Homebrew, apt

Project links

• Homepage
• Repository
• Upstream docs
• Package manager page

Commands and aliases

• virtualenvwrapper.sh
• virtualenvwrapper_lazy.sh

Project history

Hellmann introduced the idea publicly in a May 2008 Python Magazine article, explaining that he had been using virtualenv for all projects but that keeping track of many environments had become messy. The solution was a set of bash functions that wrapped virtualenv and made switching, creating, and cleaning environments routine.

The project documentation copyright and changelog history begin in the 2009 era, and the stable changelog records a 1.0 entry as the first copy and start of the new project. Over the 2.x through 4.x lines, virtualenvwrapper accumulated the conventions that made it recognizable: WORKON_HOME, project directories, pre/post activation hooks, and a plugin system.

The 5.x and 6.x era reflects the long tail of Python packaging change. The current documentation warns that 5.x requires virtualenv 20+, while the 6.x releases moved the project forward with refreshed packaging while preserving the shell-first model.

Adoption history

virtualenvwrapper became a common recommendation for Python developers who lived in bash or zsh and worked on many projects at once. It did not replace virtualenv; it standardized the human workflow around virtualenv by making environment names, activation, deletion, and per-project hooks memorable.

Its influence is visible in later tools and ports. virtualenvwrapper-win brought the idea to Windows batch scripts, while VirtualFish and other shell-specific managers borrowed the model for shells that did not use Bourne-compatible activation syntax.

How it is used

A typical setup defines WORKON_HOME, sources `virtualenvwrapper.sh` from a shell startup file, then uses `mkvirtualenv NAME` to create an environment and `workon NAME` to switch back to it. Hooks such as preactivate, postactivate, predeactivate, and postdeactivate let users automate per-environment shell state.

The package is mostly a workflow tool rather than a runtime dependency. It matters on developer machines, CI bootstrap scripts, and old-but-still-working Python development setups where quick environment switching is more valuable than a project-level lockfile system.

Why package nerds care

virtualenvwrapper is historically important because it turned virtualenv from a command you remembered into a workspace model. For package people, `workon` and WORKON_HOME became shorthand for the pre-Poetry, pre-uv period of Python environment management: practical shell glue that solved the daily mess.

Timeline

• 2008-05: Doug Hellmann published an article describing wrappers around virtualenv.
• 2009: virtualenvwrapper documentation and changelog history begin around the early project era.
• 2010: PyPI release history visible today includes 2.5.3 uploads.
• 2023: virtualenvwrapper 6.0.0 refreshed the project for modern packaging.
• 2024: virtualenvwrapper 6.1.1 was released.

Related projects

• virtualenv is the underlying environment creator. virtualenvwrapper-win is a Windows port of the same idea. VirtualFish adapts similar virtualenv-management ergonomics to the fish shell.

Sources

• Doug Hellmann's original virtualenvwrapper article: https://doughellmann.com/posts/virtualenvwrapper/
• virtualenvwrapper 6.0.0 release note: https://doughellmann.com/releases/virtualenvwrapper-6-0-0/
• virtualenvwrapper GitHub README: https://github.com/python-virtualenvwrapper/virtualenvwrapper
• virtualenvwrapper PyPI project: https://pypi.org/project/virtualenvwrapper/
• virtualenvwrapper documentation: https://virtualenvwrapper.readthedocs.io/
• virtualenvwrapper stable changelog: https://virtualenvwrapper.readthedocs.io/en/stable/history.html