virtualenv

Create a new environment

$ virtualenv [path/to/venv]

$ virtualenv --prompt [prompt_prefix] [path/to/venv]

$ virtualenv [[-p|--python]] [path/to/pythonbin] [path/to/venv]

$ source [path/to/venv]/bin/activate

$ deactivate

virtualenv [OPTIONS]

ENV_DIR: The path to the directory where the new virtual environment will be created.

-h, --help
    Show program's help message and exit.

-v, --version
    Show program's version number and exit.

-p PYTHON_EXE, --python=PYTHON_EXE
    The Python interpreter to use for the new environment. Can be an absolute path or the name of a Python executable in your PATH (e.g., python3.8).

--no-site-packages
    Do not inherit packages from the global site-packages directory. This is the default behavior in modern virtualenv versions.

--system-site-packages
    Give the virtual environment access to the global site-packages directory.

--clear
    Clear out the virtualenv environment if it already exists, before recreating it.

--symlinks
    Try to use symlinks rather than copies, when possible. This is typically the default on Unix-like systems.

--always-copy
    Always copy files instead of symlinking, even if symlinking is possible.

--no-setuptools
    Do not install setuptools in the new virtual environment.

--no-pip
    Do not install pip in the new virtual environment.

--no-wheel
    Do not install wheel in the new virtual environment.

-q, --quiet
    Suppress output during environment creation.

virtualenv is a powerful tool for Python developers that creates isolated Python environments. It allows you to have multiple Python projects on your system, each with its own independent set of installed packages, without conflicts. When you create a virtualenv, it sets up a directory containing a copy of the Python interpreter, pip, and a site-packages directory. This isolation is crucial because different projects often require different versions of the same library, or entirely different sets of libraries. Without virtualenv, installing packages globally could lead to dependency hell, where installing a new package for one project breaks another.

By activating a virtualenv, your shell's PATH is temporarily modified to point to the virtualenv's Python and pip executables. This ensures that any packages you install using pip within that environment are installed locally to that specific virtualenv, leaving your global Python installation clean and untouched. This capability promotes reproducible development environments and simplifies project dependency management.

Relocating an environment created with virtualenv can be problematic and is generally discouraged. Paths are often hardcoded, leading to issues if the environment directory is moved. It's best practice to delete and recreate the environment in the new location.

While virtualenv is highly effective, Python 3.3 and newer versions include a built-in module called venv that provides similar core functionality. For simple use cases with recent Python versions, venv might be sufficient. virtualenv remains more feature-rich and supports older Python versions not supported by venv.

After creating a virtual environment, you need to activate it to use its isolated Python interpreter and packages. This is done by sourcing an activation script:
For Linux/macOS: `source /path/to/your/env/bin/activate`
For Windows (cmd.exe): `/path/to/your/env/Scripts/activate.bat`
For Windows (PowerShell): `/path/to/your/env/Scripts/Activate.ps1`
Once activated, your shell prompt usually changes to indicate the active environment. To deactivate, simply run the command `deactivate`.

virtualenv is ideal for:

• Working on multiple Python projects simultaneously, each with different dependency versions.
• Preventing pollution of your global Python installation.
• Creating reproducible build environments for continuous integration/deployment.
• Testing packages against different Python versions or dependency sets.

The virtualenv tool was originally created by Ian Bicking in 2007. It rapidly became an essential utility for Python development, addressing the critical need for isolated development environments long before such functionality was integrated into Python itself. Its widespread adoption and success directly influenced the development of the venv module, which was introduced into the Python standard library in version 3.3. Despite the existence of venv, virtualenv continues to be actively maintained and widely used, especially for projects requiring compatibility with older Python versions, more advanced configuration options, or specific CPython builds. Its development has consistently aimed to provide a robust and flexible solution for Python environment management.

python(1), pip(1), pyenv, conda(1)