Post History

## Why

The most important ideas behind virtual environments are:

1. Since there is a separate `site-packages`, you can isolate the dependencies of your project. This is especially important for testing and development, since you can more easily verify what your project's dependencies actually are. That is, you'll be able to package the project properly, and enable Pip to install the right dependencies when *other* people use your code. Isolating dependencies like this also allows you to use a different version of a given library, rather than the one installed in the base environment.

1. By default, virtual environments will "bootstrap" Pip into them, *even if the "base" environment doesn't have Pip*. This is especially important on certain Linux installations (such as Debian-based ones), since it allows you to keep using the system package manager for the system Python (and not have to install Pip via the system package manager and risk damaging your system), while still being able to use Pip in a separate environment that can't interfere with your operating system's scripts. (The environment also contains a copy or symlink of the Pip executable wrapper.)

1. When you "activate" the environment, `python` automatically means the environment's python and `pip` means the environment's Pip, which installs to the environment's `site-packages` by default. The system is automatically configured to make sure that everything is lined up, so you won't accidentally install third-party libraries for the wrong environment. (Newer versions of Pip are aware that a virtual environment is active, and will complain if you try to use the `--user` option to bypass the virtual environment's `site-packages`.)

See [PEP 405](https://peps.python.org/pep-0405/) for technical details of how the virtual environment ensures everything is properly set up.

## What

A *virtual environment* for Python is basically a folder that contains

* a copy of, or symlink to, the Python executable that was used to create it

* possibly copies of, or symlinks to, standard library modules

* a separate `site-packages` sub-folder to store third-party libraries that are specific to this environment

* an "activation" script

* some configuration data

[Since Python 3.3, virtual environments can be created using the `venv` standard library module](https://docs.python.org/3/library/venv.html). This functionality was *not* backported to Python 2.7. Users of older Python needed to use a third-party tool such as [`virtualenv`](https://virtualenv.pypa.io/en/latest/index.html). (`virtualenv` is still maintained, and offers additional features that are missing from `venv` - but which most people won't need.)

## How

<details><summary>Creating the environment</summary>

(Linux/Mac)
```
user@machine:~$ python -m venv .venv
```
(Windows)
```
C:\Users\user\> py -m venv .venv
```
Here, `.venv` is any arbitrary name that will be used for the virtual environment's folder. (A leading dot on the filename is often desirable so that the operating system will treat the folder as "hidden".) The `python` or `py` part of the command can be replaced with [whatever makes sure that the right Python installation is used](https://software.codidact.com/posts/291616). The virtual environment will copy or symlink whichever Python interpreter was used to run `venv`.

To see a full list of options for `venv`, use the `--help` flag instead of giving a folder name: e.g. `python -m venv --help`. You can also consult the documentation linked above.
</details>
<details><summary>Activating a virtual environment</summary>

Simply run the activation script provided by the virtual environment:

(Linux/Mac)
```
user@machine:~$ source .venv/bin/activate
```

(Windows, CMD)
```
C:\Users\user\> .venv\Scripts\activate.bat
```

(Windows, [PowerShell](https://stackoverflow.com/questions/1365081))
```
PS C:\Users\user\> .venv\Scripts\activate.ps1
```
</details>
<details><summary>Deactivating a virtual environment</summary>

Use the `deactivate` command. It works the same way (although the *implementation* may differ) regardless of your operating system, and there are no command-line options for it. It simply undoes the changes that the activation script made.

<section class="notice is-warning">

**It's basically never *necessary* to activate a virtual environment**. All that activation does is change some environment variables so that the `PATH` refers to the virtual environment and the prompt reminds you about this, and set up deactivation. If you want to use the virtual environment *without* activating it, simply give the path to its Python (or Pip) explicitly. (If your virtual environment uses symlinks, *use the path to the symlink, not* the path that it's linked to.)
</section>
</details>
<details><summary>Deleting a virtual environment</summary>

Simply delete the folder, the same way you would delete any other folder.
</details>
<details><summary>Moving a virtual environment</summary>

<section class="notice is-danger">

**Virtual environments cannot reliably be relocated**. If you try to move the folder around, the environment may simply break in mysterious ways.
</section>

The simplest safe approach is to clone the environment. Use Pip to record the contents of the old environment; then create a new environment, install the recorded dependencies, and finally remove the old environment. For example, "renaming" `.venv1` to `.venv2`:

(Linux/Mac)
```
user@machine:~$ source .venv1/bin/activate
(.venv1) user@machine:~$ pip freeze > requirements.txt
(.venv1) user@machine:~$ deactivate
user@machine:~$ python -m venv .venv2
user@machine:~$ source .venv2/bin/activate
(.venv2) user@machine:~$ pip install -r requirements.txt
(.venv2) user@machine:~$ rm -rf .venv1
```

(Windows)
```
C:\Users\user\> .venv1\Scripts\activate.bat
(.venv1) C:\Users\user\> pip freeze > requirements.txt
(.venv1) C:\Users\user\> deactivate
C:\Users\user\> py -m venv .venv2
C:\Users\user\> .venv2\Scripts\activate.bat
(.venv2) C:\Users\user\> pip install -r requirements.txt
(.venv2) C:\Users\user\> rd /s /q .venv1
```
</details>