---
# System prepended metadata

title: Python Virtual Environment

---

# Python Virtual Environment

Since [python3.5](https://docs.python.org/3/library/venv.html),
*venv* is officially recommended.
A python virtual environment fixes a specific python version and isolates installed packages.

I will be using python3.6m from the official CentOS 8 repo.
The *m* suffix denotes python executables built with [pymalloc](https://docs.python.org/3/c-api/memory.html).
Pymalloc allocates memory for small objects from preallocated pools, making dynamic allocations of small objects more efficient.
On some systems, python3.6 and python3.6m could be hard links to the same inode.

A python installation includes shared libraries, modules that are callable from the python CLI, the python CLI (probably more than one, each with a different suffix), and the optional pip CLI.
If the pip command is missing on your system, you can call the pip module from the python CLI:
```
python -m pip
```
The behavior is equivalent to executing the `pip` command with the same version.
In fact, `python -m pip` is less ambiguous, as it guarantees the version consistency of pip and python.
For more information, see [this SO thread](https://stackoverflow.com/questions/25749621/whats-the-difference-between-pip-install-and-python-m-pip-install) and [the official account on installing pip](https://packaging.python.org/tutorials/installing-packages/).

Similarly, venv is a module callable from the python command that will create a python virtual environment.
With the intended python CLI, `python3.6m` in this case, issue:
```
python3.6m -m venv <dir>
```
The directory `<dir>` will be created if it doesn't already exist, and related files and directories (in particular, `bin/activate*`) will be created under `<dir>`;
much like the `.git` directory created when `git init` is employed.
Depending on your current shell, activate the virtual environment with one of these:
```
source <dir>/bin/activate
source <dir>/bin/activate.csh
source <dir>/bin/activate.fish
```
Your current shell will be rewired in several ways (check out the `bin/activate` shell script for more information) with `(<dir>)` prepending the shell prompt.
To leave the virtual environment, issue `deactivate`.
Since you are still in the same shell, `exit` will log you out if you had activated the virtual environment from a login shell.

In the virtual environment, `python` and `pip` are available, of which `python` is exactly the python CLI with which the virtual environment is created.
Check with:
```
stat $(which python)
```
In my case, the python CLI available in the virtual environment is actually a symlink, `<dir>/bin`, pointing to the system `python3.6m`.
The following commands shows that the pip CLI available in the virtual environment is the python script `<dir>/bin/pip` that, in turn, calls the pip module associated with `<dir>/bin/python`.
```
stat $(which pip)
cat $(which pip)
```

[pip tutorial](https://docs.python.org/3/tutorial/venv.html)