We're getting ready to design a package manager for Rel, the declarative relational language we're building at RelationalAI (https://relational.ai/). I know that building a package manager is a fraught task, and that people have very strong feelings about their package managers.<p>Why do you hate yours? What mistakes should we take care to avoid?<p>Or if you're one of the lucky few blessed with happy package management, what is it you love about yours?
Pkg.jl has been such a breath of fresh air vs my prior experience with Python,R, VBA. Built into language, environment management, dependency pinning, SemVer enforcement at the registry level, easy to update as a package developer.
Cargo is best there is in this domain so far. Poetry is good. I rarely use anything else.<p>Important things:<p>1. Consider what developer need and what devops need. Those are different needs.
2. Packages should be immutable.
3. Take care about what text you print. This should be to the point, no spamming.
4. Having reliable package repository is the best way to go. Getting dependencies from random git repos is a recipe for production issues, as those come and go.<p>(I do not now Rel, so maybe this is irrelevant).
It's important to resolve changes to the package environment as a whole. Pip doesn't really do this, and as of a few years ago didn't even resolve multiple CLI-specified packages together, and this causes major compatibility and consistency issues.<p>Doing this correctly can be difficult to get fast, but performance does matter. Resolving Conda environments adds way too much time to CI jobs. The Pkg.jl resolver is pretty great and we never have to wait for resolution. It's my understanding that this was a non-trivial technical problem that went through a few implementation iterations.<p>Explainability on failure to resolve is a really useful tool that becomes more difficult the more features you add. Pkg.jl has struggled with this in some cases where it hides certain version restrictions (e.g. "by explicit requirement" is rough when your project hasn't set that particular requirement). Lots of people have spent lots of time trying to identify incompatibilities over the years, and we've had to rely on people developing arcane knowledge to interpret resolution failures.<p>Immutable, cached packages is important for avoiding spending a lot of time downloading. It's very important to completely distinguish different versions/configurations though, i.e. you don't want a configuration setting that affects which code gets put at `~/mypkg/packages/<pkg-version-id>`.<p>The package source should be reliable/redundant. People will install packages in the course of normal work (automated updates, testing, etc.) and will need an always-on package manager. GitHub has proven not to be reliable enough.<p>At the same time, an offline mode should be available.<p>Getting installation configuration options right can be a big value add. I love cargo's feature flag implementation, and even Python now has "extras".<p>Every package manager eventually regrets not adding a "yank" feature.<p>Enterprise users will always eventually want to see multiple sources (private and public).<p>I appreciate when package managers consider the audience for their output and don't output line-by-line progress meters when running in a non-interactive environment.<p>Querying the package dependency tree is really useful! Both dependants and dependencies, flat and recursive. Even better if there's a library to do this that you can script and experiment with.
SemVer is very important for me.
If the language has binary dependencies the package manager should also handle them. Depending on the system for them leads to hard to debug issues.
An easy way to reproduce environments is also important via a toml file or something similar.