EnvironmentsWhat are they and how are they used?

Software environments are just files from multiple packages linked into a given folder (we also like to call it "prefix"). The mamba software environments largely follow the layout of a regular "unix"-root on Linux and macOS and have some modifications to the unix-root on Windows.

The base environment

The mamba package manager always comes with a "base" environment. The "base" environment serves two purposes: first, it contains all necessary dependencies (such as Python) for the mamba package manager to function. And secondly, it is the folder on the disk where two special folders are created: the pkgs and the envs directories.

Micromamba (the evolution of the mamba package manager) comes as a single binary. That means, it does not need a base environment for any dependencies. The base environment simply exists as a default location for the two special folders (pkgs and envs).

The envs folder

All named environments live in the envs folder. If a new environment is created using micromamba create -n myenv, a new subfolder under the envs directory with the name myenv is created. If you use the default "base" environment with micromamba which is ~/micromamba, then the myenv folder will be located under ~/micromamba/envs/myenv.

The pkgs folder

All packages are downloaded and extracted in the pkgs folder. They are then usually hard-linked into the environment. A hardlink has the advantage that the actual file only exists once on the filesystem (and only takes up space once on the disk).

Creating an environment

An environment can be created with the micromamba create command. The packages that should be used for the creation of the environment can be supplied on the command line (e.g. micromamba create -n myenv "numpy>1.20" xtensor eigen)


Note the quoting on "numpy>1.20": without quotes this would be evaluated as a shell redirection. All output of the micromamba process would be redirected to a file called 1.20 and the eigen and xtensor would not get installed.

Another way of specifying the packages that should go into an environment is with a simple YAML file. The YAML environments file has 3 fields:

# the name of the environment (can be overwritten from the command line name argument)
name: myenv

# the channels that should be used
    - conda-forge

# and the packages to install
    - numpy >1.20
    - xtensor
    - eigen

To use a file like this, the -f argument needs to be used: micromamba create -f environment.yml.

Exporting and sharing environments

Often, you want to share or export environments. There are multiple ways to do this:

  • micromamba env export --explicit
  • micromamba env export
  • conda-lock

The two micromamba environment exports differ slightly: explicitly exported environments hard-code the exact version of a package and URL to retrieve the package from. This has the advantage that the environment is exactly recreated from the exact same sources. The disadvantage is that the environment generally only works on the same operating system from which it was exported (since the operating system is hard-coded in the URL).

A benefit of explicit environments is that mamba does not need to retrieve the repodata files, which can save bandwidth and download time. Additionally, the solver is not invoked at all.

The --explicit environment export format is a simple text file that lists the URLs to retrieve the files from:

# This file may be used to create an environment using:
# $ conda create --name <env> --file <this file>
# platform: osx-arm64

Non-explicit exported environments do not specify exact URLs. They do specify packages with their version number and build string in a simple YAML environment file, e.g.:

name: myenv
    - https://conda.anaconda.org/conda-forge
    - _go_select=2.2.0=nocgo
    - anyio=3.6.2=pyhd8ed1ab_0
    - aom=3.5.0=h7ea286d_0
    - appdirs=1.4.4=pyh9f0ad1d_0
    - appnope=0.1.3=pyhd8ed1ab_0
    - argon2-cffi=21.3.0=pyhd8ed1ab_0

However, to install this environment, the package manager needs to fetch the repodata.json and resolve the environment with the solver. Additionally, also these environment files are not portable between operating system since the buildstring usually encodes the operating system as well.


Conda-lock is a third-party tool that implements powerful lockfiles for mamba / conda. micromamba is equipped to deal natively with the lockfiles produced by conda-lock. To learn more about conda-lock, visit the conda-lock documentation.