Choose Your Own (Adventure) Environment

Operating & Navigating Multiple Virtual Environments

System information and package management systems are the very foundations for any future operations to be performed using Anaconda (Python in particular). Because every environment and library comes with their own respective contents, storage, and resolutions, it is very important to have a firm grasp on what each will allow when using various system packages (local to our standard Python environment) and site packages (third party libraries).

In simpler terms, certain third party libraries which are imported to our local Python notebook may require varying versions of Python. If we’re unsure which version we have locally installed, here is the terminal code to check:

1. $ python --version
   

This poses quite the problem because we can’t just press a magic button and switch our Python version! If our system is installed with Python 3.6.9, but the site package library requires Python 3.1.0, we can create a new virtual environment to operate in with a downgraded version without uninstalling and reinstalling a different version.

Virtual Environments

A virtual environment is just an isolated environment within your system for operation. A virtual environment can have its own package dependencies without interfering or depending on others. They are actually pretty simple to create and there is no limit to how many you can have on your system, just make sure to be extra vigilant in keeping track of which environments we are currently operating in.

Creating a Virtual Environment

Fortunately, any version with Python 3 or higher will already have the necessary module in the standard library installed, so creating a new directory is the first step. This directory will be where all of our virtual environments are located:

$ mkdir python-virtual-environments && python_virtual environments

To create a new virtual environment:

$ python3 -m venv env

The venv input will require us to input which version of Python should be used to create the new environment. The directory will contain 3 components:

1. bin: holds files which will interact with the virtual environment 2. include: C headers to hold all of our Python packages 3. lib: Python version and a site-packages folder where each dependency is installed

Activating the virtual environment

Now that we have created the environment, we need to use it! The components of your new environment will not work if not activated, as we’d would still be in the original environment we started in.

$ source env/bin/activate

<env> should take the name of your environment

Whenever we see that ‘env’, it means that this is now the active environment and your system will only recognize the packages installed under that given environment.

Deactivating the virtual environment

Once we are finished with the project or notebook which uses the necessary versions, we can simply deactivate that environment and return to the default environment where we have our standard Python version.

(env) $ deactivate

The virtual environment doesn’t actually change the system in any way, rather it simply changes the directory in which it is utilizing the relative python version and it’s local packages.