The birth of a package manager
Since my time at the university, pursuing a Computer Science degree, I have always been fascinated by programming languages and the tooling around them: compilers, IDEs, package managers, etc. Eventually, that got me involved as a hobbyist in the development of the Rust compiler and rust-analyzer, but I never got the chance to work professionally on programming language tooling… until two months ago! In January, the nice folks at prefix.dev asked me to help them develop the rattler package manager, and there is lots to tell about what we have achieved since then, so buckle up!
If you are like me and have never heard of “the conda ecosystem” before, this description might leave you with more questions than you already had. The conda rabbit hole is deep, but we can get quite far with an oversimplification: the conda community maintains a repository of software packages1. Rattler is able to, given a set of dependencies, determine which exact versions need to be installed, and then proceed to install them in a virtual environment. You can also use it as a CLI, as shown below2, where we see rattler installing the cowpy package to a virtual environment, including a suitable version of python that is actually able to run cowpy (note: cargo run --release is running the rattler CLI):
Working on rattler, and probably on any package manager, brings quite a few interesting challenges on one’s path. Let’s have a look at the most relevant two!
