Save the environment with conda (and how to let others run your programs)

If you have been developing in Python, you may have tried to distribute your program to friends and colleagues. It can be mildly annoying when they try to run your program and it fails because they don't have obscurePackage42 installed. If you are nearby, then it is easy for you to call pip install a few times and get them started with your program. If you are trying to distribute a program to end users (or even some non-technical executives) then you really want something that is going to work 'out of the box'.

Conda Create Env File

Using an environment has the additional benefit of having us deal with one specific known version of Python. The problem of 'which Python am I using?' is one familiar to many of us.

With Replit, you can create an.env file to safely store your secrets. This means you can safely share your code, without sharing your secrets.env Files.env files are used for declaring environment variables. On Replit,.env files are only visible to the owner of the repl. For details on creating an environment from this environment.yml file, see Creating an environment from an environment.yml file. Restoring an environment ¶ Conda keeps a history of all the changes made to your environment, so you can easily 'roll back' to a previous version. Note: similar to Default Environment Variables,.env.test file should be included in your repository, but.env.test.local shouldn't, as.env.local are intended to be ignored through.gitignore. While running unit tests you can make sure to load your environment variables the same way Next.js does by leveraging the loadEnvConfig function from.

The old way (and its drawbacks)

One way of doing this was to write a requirements.txt file. The format of this file was pretty simple:

A single command, pip install -r requirements.txt and everything would be written to the main Python repository.

While simple to use, there are a couple of different problems with this approach:

Version conflicts: What if one application required version 0.23.4 of Pandas, but a different application required 0.19.0 (because it used a now deprecated feature)? We would have to reinstall from requirements.txt when switching between these applications.
Tracking dependencies: It can be difficult to keep track of which packages your application is actually using. You don't want to include all installed packages on your machine, as only a few are relevant to your application.

Environments were designed to address both of these issues.

Environments

An environment is a way of starting with a new Python installation, that doesn't look at your already installed packages. In this way, it simulates having a fresh install of Python. If two applications require different versions of Python, you can simply create different environments for them. If you start from a fresh environment and install as you go, you are able to generate a list of all packages installed in the environment so that others can easily duplicate it.

There are many different environments and dependency managers in the Python ecosystem. The most common ones in use are virtualenv and conda (but there are others such as poetry, pyenv/pipenv, hatch and many more I haven't heard of). This article is about using conda to manage environments, although all of these tools share the same broad goals. Some of the differences between these tools are touched on in the Alternatives section.

There are two steps to using an environment (with a third step needed if you want to use Jupyter notebooks)

Creating the environment, either from scratch (a new project) or from a yaml file (duplicating an environment)
Activating the environment for use.
Register the environment with Jupyter.

To leave an environment, we have to deactivate it. The quickstart below will walk through the typical workflow.

Using an environment (quickstart)

Let's say you wanted to create an environment test_env to do some testing with Python 3.6, and install numpy and Pandas. At the terminal, type the following:

If you want Jupyter notebooks to see your new environment, you need a couple of extra instructions. Jupyter sees the different environments as different kernels. Once we create a new environment, we need to tell Jupyter that it is there:

When loading a jupyter notebook, you can use the menu options Kernel->Change Kernel->test kernel to ensure you are using the test_env environment. (Update 2019-11-13: This process doesn't always work, this article gives you ways of checking and fixing it if it doesn't.)

Now you want to make an environment.yaml file that will allow others to recreate the environment from scratch. To make this file, we use the export command and send the output to environment.yaml:

Once we are done with the environment, we can deactivate and delete the environment:

Making the environment again from the yaml file

If you have the yaml file (created from conda env export), then recreating the environment is a single command:

Note that you don't need to supply the name of the new environment, as the yaml file also contains the name of the environment it saved. Make sure you don't give your environment an embarassing name, as everyone who recreates from the yaml file will see the name you used!

Finding conda environments on your system

Of course, you may choose to deactivate your environment but keep it around for later. If you want to see the environments installed on your system, use

Useful commands

Here is a brief summary of useful commands for environemnts. Anaconda has also published a cheat sheet with a more extensive list of useful commands.

Command
Create a new environment `ENV_NAME` with Python version 3.X	`conda create --name ENV_NAME python=3.X`
Create a new environment `ENV_NAME` with some initial packages	`conda create --name ENV_NAME python=3.X pandas ipykernel`
Create a new environment from a yaml file	`conda env create --file environment.yaml`
Activate the environment `ENV_NAME` (OSX, Linux)	`source activate ENV_NAME`
Activate the environment `ENV_NAME` (Windows)	`activate ENV_NAME`
Deactivate the current environment (*)	`source deactivate`
Delete the environment `ENV_NAME`	`conda env remove --name ENV_NAME`
List all installed environments	`conda env list`
Create a YAML file for active environment(*)	`conda env export > environment.yaml`

The commands with (*) require you to have the environment active before using them. The naming is a little odd for creating environments: if creating them yourself the command is conda create ....., but if creating them from a yaml file we use conda env create ....... This is not a typo!

Tip for maximizing portability

Some packages are system dependent (e.g. the Python Image Library Pillow is used by OSX and Linux, but not Windows). Once you create your environment.yaml file, it is often a good idea to eliminate packages you don't use directly. For example, if you tell conda to install pandas but not numpy it will figure out it needs numpy for pandas to work. You should aim to eliminate all the packages in environment.yaml except the ones you actually import, so that conda can figure out which other packages are needed for the user's system (which may be running a different operating system to yours).

Summary

Creating environments allow us to make sure users we distribute our code to have the right packages (and the right versions of those packages installed) to run our code, without interfering with other programs. We activate and environment to start using it, and deactivate to leave again.

If making a new environment that you want others to use, the workflow is

If you are using an environment someone else has created:

Alternatives

The original virtualenv. As the Jake VanderPlas article 'Conda: Myths and Misconceptions' points out, these are mostly interchangle if you are

Create An Env File