Python - Virtual Environment Example

Description

Explanation of Python virtual environments, plus helper bash script.

Bash Helper Script

To use the bash helper script, copy the contents of helper_script.sh and append it to the .bashrc file located in your user's home directory.

This script will modify the cd command to automatically detect and load/unload virtual environments when traversing folders.

Virtual Environments

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 or virtualenv.

Venv

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

For full details on installation, see https://wiki.brandon-rodriguez.com/Programming/Python/Setup.

To create a new environment, use:

python<version> -m venv <path_to_create_environment_at>

Ex:

`python3.5 -m venv ./my_environment`

Virtualenv

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

First, install with:

pip install virtualenv

To create a new environment, use:

virtualenv --python=python<verion> <path_to_create_environment_at>

Ex:

virtualenv --python=3.5 ./my_environment

Using Virtual Environments

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

In most OS's, it display in console on every line, when a Python environment is loaded. You can verify the environment loaded through 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: . ./my_env/Scripts/activate

To unload an environment, use

deactivate

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 environment on directory change (see attached helper script).

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.