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
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:
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:
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.:
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
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.