`meta_package_manager.managers.mamba` module¶

class meta_package_manager.managers.mamba.Mamba[source]¶

Bases: PackageManager

Conda-compatible package manager, reimplemented in C++.

Reaches the same channels conda does, resolving with libsolv behind a command line of its own rather than delegating to conda. It is wrapped on the same grounds as nala over apt: same archives, separate implementation. Since 2.0 it shares no code with conda at all, the Python executable of the 1.x line having been replaced by a dynamically linked build of micromamba.

Important

Every operation targets mamba’s currently active environment, which is base when none is activated. mpm neither activates nor switches environments: it inspects and mutates whatever mamba resolves from the inherited CONDA_PREFIX / CONDA_DEFAULT_ENV, exactly as a bare mamba call in the same shell would, and exactly as the conda wrapper does. Per-environment targeting is not supported yet.

Initialize cli_errors list.

operation_notes: ClassVar = {'sync': 'Nothing in the command set refreshes the index on its own; the conda wrapper implements none either, so this is parity rather than a gap.'}¶

Per-operation hints rendered in the Notes column of the manager page’s Operations table.

Keyed by the Operations member name, each value is a single short sentence explaining why the manager lacks the operation, or what makes its implementation partial: the pointer a reader needs to judge whether the gap is one they could help close. Each sentence starts with a capital and closes with a period, and starts on a word rather than a code span, so the cell reads standalone beside its row. A blank cell stays silent: a manager documenting nothing documents no gap.

The full rationale never lives here: it belongs in a comment beside the implementing method (or beside this declaration, for an operation with no method to hang it on), so the sentence on the page stays a hint and the code keeps the story. The class docstring follows the same split: it keeps only what a user needs to run the tool day to day, never how mpm wraps it.

Validated by test_operation_notes, which also checks every key matches a real operation: a key outside the enum’s vocabulary would never reach a page.

name: str = 'Mamba'¶

Return package manager’s common name.

Default value is based on class name.

homepage_url: str | None = 'https://mamba.readthedocs.io'¶

Home page of the project, only used in documentation for reference.

Left unset when the home page is the project’s repository, which repository_url names on its own, and when it is the project’s manual, which documentation_url names. Never inherited, like the other links.

documentation_url: str | None = 'https://mamba.readthedocs.io/en/latest/user_guide/mamba.html'¶

Entry point of the project’s own documentation, or None when it has none.

The manual, the documentation site, or the man page of the CLI mpm drives: whichever page a user reads to learn the commands this manager wraps. Listed between homepage_url and repository_url in the links of the manager’s page, so a reader reaching for the tool’s reference finds it in the box of facts rather than in the prose below it.

Left unset where a link would state a fact twice or invent one: a tool documenting itself in its repository alone, whose README repository_url already reaches. A page about the ecosystem rather than the tool does not qualify either.

Where a project’s only site is its manual, that address belongs here and homepage_url stays unset: the slot names what the page is, and a reader reaching for the reference looks under the documentation link.

Never inherited, like every other link: the AUR helpers extending pacman each document themselves.

repository_url: str | None = 'https://github.com/mamba-org/mamba'¶

Repository holding the project’s code, or None when it has no public one.

Linked from the manager’s documentation page. Also what the weekly metrics sample reads: docs/docs_update.py writes it into the [tool.repomatic.metrics] subjects of pyproject.toml when its forge answers the sampler, through a mirror for a forge that does not.

Never inherited, for the same reason as wikipedia_url: the AUR helpers extending pacman each live in a repository of their own.

logo: str | None = 'anaconda'¶

Slug of the brand mark standing for this manager in the documentation.

Names an SVG vendored under docs/assets/managers/, whose provenance and license are recorded in docs/assets/managers/logos.yaml. Inlined at the top of the manager’s page by meta_package_manager._docs; a manager leaving it unset keeps the page’s default package glyph.

Several managers legitimately share one slug, either because they wrap the same upstream (brew and cask) or because the tool has no mark of its own and its ecosystem’s stands in (apt under Debian’s swirl, cargo under Rust’s gear). Documentation-only, like homepage_url: no CLI output reads it.

platforms: frozenset[Platform] | Group | Platform | Iterable[Platform | Group] = frozenset({Platform(id='almalinux', name='AlmaLinux'), Platform(id='alpine', name='Alpine Linux'), Platform(id='altlinux', name='ALT Linux'), Platform(id='amzn', name='Amazon Linux'), Platform(id='android', name='Android'), Platform(id='arch', name='Arch Linux'), Platform(id='buildroot', name='Buildroot'), Platform(id='cachyos', name='CachyOS'), Platform(id='centos', name='CentOS'), Platform(id='chromeos', name='ChromeOS'), Platform(id='clearlinux', name='Clear Linux OS'), Platform(id='cloudlinux', name='CloudLinux OS'), Platform(id='crux', name='CRUX'), Platform(id='debian', name='Debian'), Platform(id='endeavouros', name='EndeavourOS'), Platform(id='exherbo', name='Exherbo Linux'), Platform(id='fedora', name='Fedora'), Platform(id='generic_linux', name='Generic Linux'), Platform(id='gentoo', name='Gentoo Linux'), Platform(id='guix', name='Guix System'), Platform(id='ibm_powerkvm', name='IBM PowerKVM'), Platform(id='kali', name='Kali Linux'), Platform(id='kvmibm', name='KVM for IBM z Systems'), Platform(id='linuxmint', name='Linux Mint'), Platform(id='macos', name='macOS'), Platform(id='mageia', name='Mageia'), Platform(id='mandriva', name='Mandriva Linux'), Platform(id='manjaro', name='Manjaro Linux'), Platform(id='nixos', name='NixOS'), Platform(id='nobara', name='Nobara'), Platform(id='nutyx', name='NuTyX'), Platform(id='opensuse', name='openSUSE'), Platform(id='openwrt', name='OpenWrt'), Platform(id='oracle', name='Oracle Linux'), Platform(id='parallels', name='Parallels'), Platform(id='pidora', name='Pidora'), Platform(id='pikaos', name='PikaOS'), Platform(id='raspbian', name='Raspbian'), Platform(id='rhel', name='RedHat Enterprise Linux'), Platform(id='rocky', name='Rocky Linux'), Platform(id='scientific', name='Scientific Linux'), Platform(id='slackware', name='Slackware'), Platform(id='sles', name='SUSE Linux Enterprise Server'), Platform(id='slitaz', name='SliTaz GNU/Linux'), Platform(id='solus', name='Solus'), Platform(id='sourcemage', name='Source Mage GNU/Linux'), Platform(id='tuxedo', name='Tuxedo OS'), Platform(id='ubuntu', name='Ubuntu'), Platform(id='ultramarine', name='Ultramarine'), Platform(id='void', name='Void Linux'), Platform(id='windows', name='Windows'), Platform(id='wsl1', name='Windows Subsystem for Linux v1'), Platform(id='wsl2', name='Windows Subsystem for Linux v2'), Platform(id='xenserver', name='XenServer')})¶

List of platforms supported by the manager.

Allows for a mishmash of platforms and groups of platforms. Will be normalized into a frozenset of Platform instances at instantiation.

requirement: str | None = '>=2.0.0'¶

The release that made mamba a standalone C++ program.

Chosen over the newer 2.9.0, where the inventory settled on one shape, so the floor does not exclude the releases users still run: installed() reads both shapes instead.

version_regexes: tuple[str, ...] = ('^(?P<version>\\d+\\.\\d+\\.\\d+\\S*)$',)¶

Search the bare version mamba reports.

$ mamba --version
2.9.0

Anchored at both ends because the output is the version and nothing else: mamba prints no program name to key on, unlike conda’s conda 24.5.0. The patterns are applied in multiline mode, so the anchors bind to the line.

property installed: Iterator[Package]¶

Fetch installed packages.

$ mamba list --json
{
    "log_history": [],
    "packages": [
        {
            "base_url": "https://conda.anaconda.org/conda-forge",
            "build_number": 2,
            "build_string": "h23cfdf5_2",
            "channel": "conda-forge",
            "dist_name": "libiconv-1.18-h23cfdf5_2",
            "md5": "4d5a7445f0b25b6a3ddbb56e790f5251",
            "name": "libiconv",
            "platform": "osx-arm64",
            "url": "https://conda.anaconda.org/conda-forge/osx-arm64/libiconv-1.18-h23cfdf5_2.conda",
            "version": "1.18"
        }
    ]
}

Caution

Two payload shapes are accepted, and reading the wrong one is silent. 2.9.0 wrapped this array in an envelope carrying a log_history sibling, where every release before it printed the array bare, the way conda still does. Neither shape raises on the other’s reader: it simply finds no list and reports an empty inventory, so the array is located by shape rather than by a fixed path.

That same envelope is why success is read from the exit code and the presence of packages, never from the output parsing. Pointed at a prefix that does not exist, 2.9.0 exits non-zero with an empty stderr and tens of kilobytes of trace on stdout, as JSON that parses perfectly and holds no packages.

property outdated: Iterator[Package]¶

Fetch outdated packages.

mamba inherits conda’s lack of a dedicated outdated command, and its dry-run reports the same actions mapping, so the upgrade the solver would perform is simulated and its UNLINK (current) and LINK (candidate) sets are diffed by name. A package in both is an in-place upgrade; one in only LINK is a freshly pulled dependency and one in only UNLINK is a removal, so neither is reported.

$ mamba update --all --dry-run --json
{
    "actions": {
        "LINK": [
            {
                "build": "h23cfdf5_2",
                "fn": "libiconv-1.18-h23cfdf5_2.conda",
                "name": "libiconv",
                "version": "1.18"
            }
        ],
        "PREFIX": "/opt/conda",
        "UNLINK": [
            {
                "build": "h23cfdf5_1",
                "fn": "libiconv-1.17-h23cfdf5_1.conda",
                "name": "libiconv",
                "version": "1.17"
            }
        ]
    },
    "dry_run": true,
    "log_history": [],
    "prefix": "/opt/conda",
    "success": true
}

When the environment is already current, the actions key is omitted exactly as conda omits it:

$ mamba update --all --dry-run --json
{
    "dry_run": true,
    "log_history": [],
    "message": "All requested packages already installed",
    "prefix": "/opt/conda",
    "success": true
}

Note

repoquery was assessed for this and cannot answer it: it reads channels and installed metadata but never solves, so it cannot say what a transaction would do. Entries here also carry libmamba’s wider field set instead of conda’s, and no FETCH key, neither of which is read.

search(query, extended, exact)[source]¶

Fetch matching packages.

Caution

Search does not support extended matching, mamba exposing no package description to match against. Exact matching is native: a bare query resolves against the package name alone, where wrapping it in * widens it to a substring match.

$ mamba search "*zstd*" --json
{
    "log_history": [],
    "query": {
        "query": "*zstd*",
        "type": "search"
    },
    "result": {
        "msg": "",
        "pkgs": [
            {
                "build": "py313h7208f8c_0",
                "name": "backports.zstd",
                "version": "1.6.0"
            }
        ],
        "status": "OK"
    }
}

Caution

Results are a flat list under result.pkgs, not conda’s mapping of name to builds, so they are grouped here by name. The newest build of each group is picked by comparing versions rather than by position: mamba sorts descending where conda sorts ascending, and that order was a string comparison before 2.6.0, which misplaces 1.10 against 1.9. Comparing parsed versions is right whatever the release does.

A query matching nothing exits zero with an empty pkgs, unlike conda’s non-zero PackagesNotFoundError payload.

Return type:: Iterator[Package]

install(package_id, version=None)[source]¶

Install one package, optionally pinned to a version.

mamba accepts a MatchSpec, so the version is appended with =.

$ mamba install --yes zstd

Return type:: str

upgrade_all_cli()[source]¶

Generates the CLI to upgrade all packages.

$ mamba update --all --yes

Return type:: tuple[str, ...]

upgrade_one_cli(package_id, version=None)[source]¶

Generates the CLI to upgrade the package provided as parameter.

$ mamba update --yes zstd

Return type:: tuple[str, ...]

remove(package_id)[source]¶

Removes a package.

$ mamba remove --yes zstd

Return type:: str

cleanup_cache()[source]¶

Removes things we don’t need anymore.

$ mamba clean --all --yes

Return type:: None

cli_names: tuple[str, ...] = ('mamba',)¶

List of CLI names the package manager is known as.

This list of recognized CLI names is ordered by priority. That way we can influence the search of the right binary.

..hint::: This was helpful in the case of the Python transition from 2.x to 3.x, where multiple versions of the same executable were named python or python3.

By default, this property’s value is derived from the manager’s ID (see the MetaPackageManager.__init__ method above).

id: str = 'mamba'¶

Package manager’s ID.

Derived by defaults from the lower-cased class name in which underscores _ are replaced by dashes -.

This ID must be unique among all package manager definitions and lower-case, as they’re used as feature flags for the mpm CLI.

virtual: bool = False¶

Should we expose the package manager to the user?

Virtual package manager are just skeleton classes used to factorize code among managers of the same family.

wikipedia_url: str | None = None¶

English Wikipedia article about the project, or None when it has none.

Listed last in the links of the manager’s documentation page. The article covers the project that home page names, or is a redirect Wikipedia keeps under the project’s name, landing on the part of a broader article that describes it: Cargo_(software) opens the Cargo section of the Rust article. An article that merely mentions the project does not count, nor does one about a related subject: lazy is a Neovim plugin manager, and the Neovim article is not about it.

Never inherited: the metaclass resets it to None on any class not declaring its own. A subclass often wraps a distinct project, like the six AUR helpers extending pacman, and would otherwise present pacman’s article as its own. Documentation-only, like homepage_url.

class meta_package_manager.managers.mamba.Micromamba[source]¶

Bases: Mamba

mamba’s statically linked build, shipped as a single self-contained binary.

The same program as mamba, built the other way: upstream’s build declares “mamba is a dynamic build of micromamba” and compiles both executables from one source list. Every operation, parser and forced argument is therefore inherited unchanged.

Note

The two are separate managers rather than one manager naming both binaries, because they resolve different root prefixes: mamba takes the conda installation it ships inside, while micromamba takes ~/micromamba or its XDG data directory. mpm resolves a manager to the first of its CLI names found while walking the search path, so a host carrying both would silently report whichever came first on PATH and hide the other’s packages entirely.

Note

Their command sets differ by exactly one entry: micromamba adds self-update, which the dynamic build rejects. It maps to no mpm operation, so nothing here uses it.

Initialize cli_errors list.

id: str = 'micromamba'¶

Package manager’s ID.

Derived by defaults from the lower-cased class name in which underscores _ are replaced by dashes -.

This ID must be unique among all package manager definitions and lower-case, as they’re used as feature flags for the mpm CLI.

name: str = 'Micromamba'¶

Return package manager’s common name.

Default value is based on class name.

homepage_url: str | None = 'https://mamba.readthedocs.io'¶

Home page of the project, only used in documentation for reference.

documentation_url: str | None = 'https://mamba.readthedocs.io/en/latest/user_guide/micromamba.html'¶

Entry point of the project’s own documentation, or None when it has none.

Never inherited, like every other link: the AUR helpers extending pacman each document themselves.

repository_url: str | None = 'https://github.com/mamba-org/mamba'¶

Repository holding the project’s code, or None when it has no public one.

Never inherited, for the same reason as wikipedia_url: the AUR helpers extending pacman each live in a repository of their own.

virtual: bool = False¶

Should we expose the package manager to the user?

Virtual package manager are just skeleton classes used to factorize code among managers of the same family.

wikipedia_url: str | None = None¶

English Wikipedia article about the project, or None when it has none.

cli_names: tuple[str, ...] = ('micromamba',)¶

List of CLI names the package manager is known as.

This list of recognized CLI names is ordered by priority. That way we can influence the search of the right binary.

..hint::: This was helpful in the case of the Python transition from 2.x to 3.x, where multiple versions of the same executable were named python or python3.

By default, this property’s value is derived from the manager’s ID (see the MetaPackageManager.__init__ method above).

meta_package_manager.managers.mamba module¶

`meta_package_manager.managers.mamba` module¶