Mamba 0.15.0

We’ve just dropped one of the biggest releases of mamba (the fast conda package manager)— along with some nice improvements in libsolv!

This is a quick update on some new and improved features in mamba 0.15.0. The full changelog can be found here.

• We’ve improved the resolution behaviour of libsolv for conda packages. Before, for certain “variant packages” the behaviour was not well specified. For instance, conda-forge provides ~6 variants for NumPy with the same version and build number: variants for PyPy 3.6, PyPy 3.7 and CPython 3.6 to 3.9. libsolv did not have a mechanism to prefer any of these variants. Our recent patches fixes that. If libsolv now encounters variants it will also compare the first-order dependencies to figure out which variant will pull in the most desired dependencies (dependencies of higher version and without any “track-features”). We’ve also documented the resolver behaviour so that users and packagers can understand better what happens and why.
• Mamba 0.15 fully supports verifying cryptographic repodata signatures. Here we’re following the spec of conda content trust, but we’re already thinking about some important improvements to make the performance feasible in the conda-forge context. We hope that by the end of the year we can start attaching signatures to conda-forge repodata so that we add a layer of trust to the conda-forge packaging ecosystem. We’re planning to roll out support in the open source quetz conda package server for signing repodata in the upcoming months.
• Micromamba (the pure C++ implementation of mamba) is gearing up for interactive use — it now has condarc / mambarc file reading in place and supports most widely used conda commands. It’s a blissful experience and is used by team-members on a day-to-day basis. We’re polishing the remaining rough edges and we’re in the process of figuring out how to roll it out to everyone.
• We’ve got a new syntax to support explicit specification of subdirs. When adding -c mychannel[linux-static64, linux-64, noarch] mamba will fetch 3 subdirs from mychannel and use them all for package resolution (this was an awesome contribution by GitHub user afranchuk).Additionally with micromamba you can specify a platform in your environments .condarc file to default to — this is useful for example on new MacBooks since it let’s one select x64 macOS easily where packages are not yet available and run them with Rosetta2. Just put platform: osx-64 into the condarc file for that.
• We’ve changed our channel priorities to better match conda: previously our “strict” channel priority was not really strict enough (one could still select from lower-prio channels when a requirement couldn’t otherwise be fulfilled).
  The new behavior is much closer to conda:
  Strict: if a package name exists in a higher prio channel, completely ignore other channels for that package name.
  Flexible (default): if a package name exists in a higher prio channel, ignore other channels for that package name unless the version to fulfil a requirement is not available from a higher prio channel.
  Disabled: sort by version number first, and then by channel priorities.
• We’ve got some other solver related improvements, such as adding a --freeze-installed flag and better pruning of unneeded packages when removing packages.
• We’re moving functions to “libmamba” to facilitate bindings, for example to the R language as explained in this blog post.

The road to 1.0

To conclude: lots of updates! We’re working hard towards releasing a 1.0 later this year. We really think the latest solver updates have improved the resolution quality by another great notch and we’re pretty happy with the current status. In our mind, 0.15.0 is the last release before 1.0 so make sure to test it thoroughly!

During the past months we’ve seen more and more community adoption of mamba in all sorts of places and we’re really happy about that — the mybinder project has been using mamba successfully for a while now, and even ReadTheDocs is considering a more widespread rollout of mamba to install conda packages. We’ve also heard some really nice success stories from bigger enterprise users — if you’re one of them and want to work with us or sponsor mamba development, you should consider to drop us a line at info@quantstack.net!

Other mamba-org projects

We’re also seeing more and more use of boa (the fast conda-package builder) in the conda-forge project and elsewhere (people are starting to use it locally and to debug builds on conda-forge). Given the wide-spread use of mamba in CI systems it might be time to start thinking of rolling out proper boa support in conda-forge.

Sneak peek of the new quetz UI

As for quetz (the open source conda package server)— we’ll share more updates soon — but we’ve recently released fresh packages to conda-forge, and we got a completely new frontend that is fully extensible. Excitingly we’re using the same plugin mechanism as jupyterlab that should make it easy to distribute quetz plugins with both a front- and backend as pip or conda packages.

Authors

Wolf Vollprecht
Wolf Vollprecht works at QuantStack and started the mamba-project. He also contributed to the xtensor numerical library, and tries to bring the ROS Robotics community to the conda package world. Twitter

Adrien Delsalle
Adrien Delsalle is a scientific software developer at QuantStack. He is currently working on the mamba and xtensor stacks.