Python - Logging Example

Author

Brandon Rodriguez

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 separate Python package installations, to prevent conflicts between different projects.

Through Virtual Environments, you can even easily access different Python versions between different projects. For example, you could have a Python3.7 installation for Django, a Python3.5 installation for wxPython, and a Python2.7 installation for general script usage.

As of writing this, there are two recommended ways to setup Virtual Environments: the virtualenv Python package or the venv package.

Venv

The venv package is generally shipped with Python3, although some OS distros separate it into a distro package (for example, on Ubuntu, install with apt install python3-venv).

This method will only work with Python version 3 or higher.

• To use, call python<version> -m venv </path/to/new/virtual/environment>.
  • Ex: python3.5 -m venv ./my_environment

Virtualenv

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

This method can be used on any Python version.

• First, install with pip install virtualenv.
• To use, call virtualenv --python=python<verion> </path/to/new/virtual/environment>.
  • Ex: virtualenv --python=3.5 ./my_environment

Using Virtual Environments

Either of the above methods should essentially provide the same result.

• Linux/Mac:
  • To load an environment, use source </path/to/environment>/bin/activate.
    • Ex: source ./my_env/bin/activate
    • When successfully loaded, the console will generally display the name of the environment.
  • To unload an environment, use deactivate.
    • When successfully unloaded, the console will no longer display the name of the environment.

Organizing Virtual Environments

There are two general practices for organizing 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.1, ~/Env/wxPython, and ~/Env/Django1.8.

The benefit of this method is that you can reuse the same environment for multiple different projects. However, there is no way to get the console to automatically import your desired environment. You'll have to manually select it with the above commands.

An Environment for Each Project

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

For example, if you might have /my_project/.venv, and would repeat for every Python project.

The benefit of this method is that you can set up your console to automatically load the environment on cd (see attached helper script). However, if you have multiple projects that use the same packages, you'll still need to create separate environments for each one.