Programming/Python/Setup

Virtual Environments

In Python, Virtual Environments are a way to separate Python package installations, in order to prevent conflicts between different project setups.

Environment Setup

As of 2020, there are two recommended ways to setup Virtual Environments.

Venv

The venv package is shipped with Python3 on windows. It also ships with some Python3 distributions on Linux systems.

To create a new environment, use:

python<version> -m venv <path_to_create_environment_at>

For example, if you wanted a Python3.5 environment called MyEnv in your local user home directory, then use:

python3.5 -m venv ~/MyEnv

Virtualenv

Virtualenv is a third party package that's officially supported by the PyPA (Python Packaging Authority).

First, install with:

pip install virtualenv

To createa new environment, use:

virtualenv --python=python<version> <path_to_create_environment_at>

For example, if you wanted a Python3.5 environment called MyEnv in your local user home directory, then use:

virtualenv --python=3.5 ~/MyEnv

Using Virtual Environments

Regardless of which above method you used to install the environment, you load them the same way.

Note: In most OS's, it display in console on every line, when a Python environment is loaded. You can further verify an environment has loaded via the which python, which pip, python -V, and pip -V commands.

Linux/Mac

To load an environment, use:

source <path_to_environment>/bin/activate

Ex:

source ./my_env/bin/activate

To unload an environment, use:

deactivate

Windows

To load an environment, use:

. <path_to_environment>/Scripts/activate

Ex:

. <path_to_environment>/Scripts/activate

Organizing Virtual Environments

There are two general practices for organizing Virtual Environments. Generally speaking, most prefer the first option, which creates a new environment for each project.

An Environment for Each Project

This method involves creating an environment (usually labeled .venv) at the root of every project.

This keeps all of your dependencies isolated for every project, which is particularly useful for mimicking and testing production setups.

Furthermore, it's possible to set up your console to automatically load these environments on directory change. See https://git.brandon-rodriguez.com/python/example_projects/virtual_environments.

Multiple Environments in a Central Location

This method involves creating all your virtual environments in a single location (for example, ~/Env/).

For example, you might have ~/Env/Django2.0, ~/Env/wxPython, and ~/Env/Django3.0.

The benefit of this method is that you can reuse the same environment for multiple different projects, which results in less time setting up and maintaining environments.

However, you might get package conflicts between projects. Furthermore, there is no way to have the console to automatically import your desired environment. You'll have to manually select it with the above commands.

ToDo: link to commands