Managing Python environments and Jupyter kernels

Many projects that use Python code require careful management of the respective Python environments. Rapid changes in package dependencies, package version conflicts, deprecation of APIs (function calls) by individual projects, and obsolescence of system drivers and libraries make it virtually impossible to use an arbitrary set of packages or create one all-encompassing environment that will serve everyone's needs over long periods of time. The high velocity of changes in the popular ML/DL frameworks and packages and GPU computing exacerbates the problem.

The problem with pip install

Expand this section to view pip problems and how conda/mamba mends them.

Most guides and project documentation for installing python packages recommend using pip install for package installation. While pip is easy to use and works for many use cases, there are some major drawbacks. There are a few issues with doing pip install on a supercomputer like HiPerGator:

• Pip by default installs binary packages (wheels), which are often built on systems incompatible with HiPerGator. This can lead to importing errors, and its attempts to build from source will fail without additional configuration.
• If you pip installing a package that is/will be installed in an environment provided by UFRC, your pip version will take precedence. Your dependencies eventually become incompatible causing errors, with even one pip install making environments unusable.
• Different packages may require different versions of the same package as dependencies leading to impossible to reconcile installation scenarios. This becomes a challenge to manage with pip as there isn't a method to swap active versions.
• On its own, `pip` installs **everything** in one location: ~/.local/lib/python3.X/site-packages/.

Conda and Mamba to the rescue!

conda and the newer, faster, drop-in replacement mamba, were written to solve some of these issues. They represent a higher level of packaging abstraction that can combine compiled packages, applications, and libraries as well as pip-installed python packages. They also allow easier management of project-specific environments and switching between environments as needed. They make it much easier to report the exact configuration of packages in an environment, facilitating reproducibility. Moreover, conda environments don't even have to be activated to be used; in most cases adding the path to the conda environment's 'bin' directory to the $PATH in the shell environment is sufficient for using them.

Check out the UFRC Help page on conda for additional information.

A caveat

conda and mamba get packages from channels, or repositories of prebuilt packages packages. While there are several available channels, like the main conda-forge, not every Python package is available from a conda channel as they have to be packaged for conda first. You may still need to use pip to install some packages as noted later. However, conda still helps manage environment by installing packages into separate directory trees rather than trying to install all packages into a single folder that pip does.

Configuring Conda

Follow the instructions at Conda Configuration

Create and activate your first environment

Follow the instructions at Create and Activate Environments

Install packages into our environment with mamba or pip

Expand this section to view instructions.

Now we are ready to start adding things to our environment.

There are a few ways to do this. We can install things one-by-one with either mamba install ____ or pip install ____. We will look at using yaml files below.

Note: when an environment is active, running pip install will install the package into that environment. So, even if you continue using pip, adding conda environments solves the problem of everything being installed in one location--each environment has its own site-packages folder and is isolated from other environments.

mamba install packages

Now we are ready to install packages using mamba install ___.

Start with cudatoolkit and pytorch/tensorflow if using GPU!

If you plan on using a GPU: it is important to both make the environment on a node with a GPU (within a Jupyter job for example) and to start by installing the cudatoolkit and pytorch, tensorflow or other frameworks.
If you just mamba install tensorflow, you will get a version compiled with an older CUDA, which will be extremely slow or not recognize the GPU at all...ask me how I know 🤦. Same for pytorch.

From the PyTorch Installation page, we should use:

mamba install pytorch torchvision torchaudio cudatoolkit=11.3 -c pytorch

When you run that command, mamba will look in the repositories for the specified packages and their dependencies. Note we are specifying a particular version of cudatoolkit. As of May, 2022, that is the correct version on HiPerGator.

Here's a screenshot of part of the output:

mamba will list the packages it will install and ask you to confirm the changes. Typing 'y' or hitting return will proceed; 'n' will cancel:

Finally, mamba will summarize the results:

Tensorflow installation alternative

While not needed for this tutorial, many users will want TensorFlow instead of PyTorch, so we will provide the command for that here. To install TensorFlow, use this command:

mamba install tensorflow cudatoolkit=11.2

This post at conda-forge has additional information and tips for installing particular versions or installing on a non-GPU node: GPU enabled TensorFlow builds on conda-forge.

Install additional packages

This tutorial creates an environment for the Hugging Face Deep Reinforcement Learning Course, you can either follow along with that or adapt to your needs.

You can list more than one package at a time in the mamba install command. We need a couple more, so run:

mamba install gym-box2d stable-baselines3

Add packages to our environment with pip install

As noted above, not everything is available in a conda channel. For example the next thing we want to install is huggingface_sb3.

If we type mamba install huggingface_sb3, we get a message saying nothing provides it as seen to the right:

If we know of a conda source that has that package, we can add it to the channels: section of our ~/.condarc file. That will prompt mamba to include that location when searching.

But many things are only available via pip. So...

pip install huggingface_sb3

That will install huggingface_sb3. Again, because we are using environments and have the hfrl environment active, pip will not install huggingface_sb3 in our ~/.local/lib/python3.X/site-packages/ directory, but rather within in our hfrl directory, at /blue/group/user/conda/envs/hfrl/lib/python3.10/site-packages. This prevents the issues and headaches mentioned at the start.

Install additional packages

As with mamba, we could list multiple packages in the pip install command, but again, we only need one more:

pip install ale-py==0.7.4

Use your kernel from command line or scripts

Now that we have our environment ready, we can use it from the command line or a script using something like:

module load conda conda activate hfrl # Run my amazing python script python amazing_script.py

or with path based environments:

# Set path to environment we want and pre-pend to PATH variable env_path=/blue/mygroup/share/project42/conda/bin export PATH=$env_path:$PATH # Run my amazing python script python amazing_script.py

Setup a Jupyter Kernel for our environment

Expand this section to view instructions.

Often, we want to use the environment in a Jupyter notebook. To do that, we can create our own Jupyter Kernel.

Add the jupyterlab package

In order to use an environment in Jupyter, we need to make sure we install the jupyterlab package in the environment:

mamba install jupyterlab

Copy the template_kernel folder to your path

On HiPerGator, Jupyter looks in two places for kernels when you launch a notebook:

1. /apps/jupyterhub/kernels/ for the globally available kernels that all users can use. (Also a good place to look for troubleshooting getting your own kernel going)
2. ~/.local/share/jupyter/kernels for each user. (Again, your home directory and the .local folder is hidden since it starts with a dot)

Make the ~/.local/share/jupyter/kernels directory: mkdir -p ~/.local/share/jupyter/kernels

Copy the /apps/jupyterhub/template_kernel folder into your ~/.local/share/jupyter/kernels directory:

cp -r /apps/jupyterhub/template_kernel/ ~/.local/share/jupyter/kernels/hfrl

Note: This also renames the folder in the copy. It is important that the directory names be distinct in both your directory and the global /apps/jupyterhub/kernels/ directory.

Edit the template_kernel files

The template_kernel directory has four files: the run.sh and kernel.json files will need to be edited in a text editor. We will use nano in this tutorial. The logo-64X64.png and logo-32X32.png are icons for your kernel to help visually distinguish it from others. You can upload icons of those dimensions to replace the files, but they need to be named with those names.

Edit the kernel.json file

Let's start editing the kernel.json file. As an example, we can use:

nano ~/.local/share/jupyter/kernels/hfrl/kernel.json

The template has most of the information and notes on what needs to be updated. Edit the file to look like:

{
 "language": "python",
 "display_name": "HF_Deep_RL",
 "argv": [
  "~/.local/share/jupyter/kernels/hfrl/run.sh",
  "-f",
  "{connection_file}"
 ]
}

Edit the run.sh file

The run.sh file needs the path to the python application that is in our environment. The easiest way to get that is to make sure the environment is activated and run the command: which python

The path it outputs should look something like: /blue/group/user/conda/envs/hfrl/bin/python. Copy that path.

Edit the run.sh file with nano:

nano ~/.local/share/jupyter/kernels/hfrl/run.sh

The file should looks like this, but with your path:

#!/usr/bin/bash

exec /blue/ufhpc/magitz/conda/envs/hfrl/bin/python -m ipykernel "$@"

If you are doing this in a Jupyter session, refresh your page. If not, launch Jupyter.

Your kernel should be there ready for you to use!

Export or import an environment

Expand this section to view instructions.

Export your environment to an environment.yml file

Now that you have your environment working, you may want to document its contents and/or share it with others. The environment.yml file defines the environment and can be used to build a new environment with the same setup.

To export an environment file from an existing environment, run:

conda env export > hfrl.yml

You can inspect the contents of this file with cat hfrl.yml. This file defines the packages and versions that make up the environment as it is at this point in time. Note that it also includes packages that were installed via pip.

Create an environment from a yaml file

If you share the environment yaml file created above with another user, they can create a copy of your environment using the command:

conda env create --file hfrl.yml

They may need to edit the last line to change the location to match where they want their environment created.

Group environments

It is possible to create a shared environment accessed by a group on HiPerGator, storing the environment in, for example, /blue/group/share/conda. In general, this works best if only one user has write access to the environment. All installs should be made by that one user and should be communicated with the other users in the group.