More concepts#


This section complements concepts with advanced terminology.

While not necessary to understand the basic usage, those advanced concepts are fundamental to understand Mamba in details.

Packages repository#

A packages repository, also called repo, is a generic way to describe a storage location for software packages.

In the Mamba’s context, it may points to a packages server, a channel or a subdir.


A channel is an independant and isolated repo structure that is used to classify and administrate more easily a packages server.


A packages server may host one or multiple channels.


A subdir is a channel subdirectory specific to a given operating system/platform pair.

Mamba is a general purpose, langage agnostic package manager. The subdir structure is a convenient way to provide and access packages depending on the targeted os and platform.

Typically linux-64, osx-arm64 or win-64 but not limited to those ones.

A subdir provides the packages tarballs alongside a packages index including additional metadata.


In most cases, both noarch and <os>-<platform> subdirs are used for an operation requiring data from the repo

Packages index#

A repository package index is a file containing metadata about all the packages tarballs served by a repo.


Those metadata include license, file size, checksums, etc.

In Mamba, it is more often called a repodata in reference to the index filename repodata.json.

A repodata is specific to a channel subdirectory.

Package tarball#

A tarball is a single archive file, compressed or not, that expands to multiples files/directories. It is typically a zip file or so.

In the case of Mamba, 2 conda formats are used as package tarball:

  • tar.bz2 is the historical formats: a tar file/ball that has been compressed using bzip2 algorithm

  • conda more recent format that allows faster access to packages metadata


Each package contains its files index, used at a step called linking. The linking consists in creating a link between the package cache where the tarballs are expanded into multiple directories/files and the installation target prefix.

The 3 kinds of links are:

The default behavior is to use hard-links and fallback to copy.

The advanced user may want to change that behavior using configuration (see the relevant CLI or API reference for more details):

  • allow soft-links to be used as a prefered fallback to copy (try to copy if soft-link fails)

  • use soft-links instead of hard-links as default behavior (copy is still a fallback)

  • always copy instead of hard-links as default behavior (no fallback then)


soft-links more easily lead to broken environment due to their property of becoming invalid when the target is deleted/moved


This is a most well-known link, a simple copy of the file is done.

It is not efficient nor resource friendly but preserve the file from deletion/modification of the reference.