Around 2019, solving a conda environment could take long enough to get lunch, and it was getting worse as the ecosystem grew. Mamba, a C++ reimplementation of the core of conda, fixed that. A few years later, at prefix.dev, we did it again in Rust. Why was the conda ecosystem worth saving twice?

Because conda’s package model is the right one for a lot of scientific computing. A conda package can be a compiler, a CUDA runtime, an R library, a Fortran solver or a ROS node, and they all link against the same shared libraries. conda-forge, the community distribution behind most of this, is one of the most valuable and least appreciated pieces of infrastructure in open source science. PyPI has caught up in many places with wheels, but it was designed around a different problem, and the differences in distribution model and package format still matter.

I’ll walk through both models, where each one wins, and how we rebuilt the conda stack from the inside to catch up with what the PyPI world got right: fast resolution, lockfiles, and a project workflow people actually want to use.

Conda has real problems too, and there are good reasons Python developers default to PyPI. Some of it is old design debt. Some of it is the defaults licensing mess. A lot of it is too many tools and too much confusion about which one to use. I’ll talk about those honestly, including the parts we contributed to.
The future of the Conda ecosystem is quite exciting, with much more interesting work to come. If you have ever had to make scientific software install on someone else’s machine, this talk is for you. You don’t need to know anything about Conda.