What do package managers do? Install packages, obviously! But that is not everything. In my opinion, package managers do enough to be characterized as general automation frameworks. For example:
- manage configurations and configuration files
- manage custom compilation options and flags
- provide isolation or containerization
- make sure a specific file is present in a specific place given specific conditions
- change installation files or configuration based on architecture or other conditions
Not all package managers do all of the above, but you get the idea.
Nix even manages your entire setup with a single configuration file.
It occurred to me that package management could theoretically be managed by an automation framework.
What do I mean by automation framework? Ansible, chef, puppet, or Sparrow.
Now imagine if you were to use one of those package managers as an automation framework. For most of them, it would suck. (nix is a notable exception). So maybe common package managers are just bad automation frameworks?
What if we used an automation framework as a package manager? Well currently, it might also suck, but only because it lacks the package definitions. Maybe it is not a bad experiment to have a distribution managed by a modern automation framework like Sparrow.
What are the benefits?
- usable on other distributions
- more easily create your own packages on the fly
- Greater customization and configurability
- use a known programming language that is easy to read to define packages and other functions, instead of a DSL
- your package manager can easily automate just about any task using the same syntax and framework
Why has it caused you regret?
Nothing wrong with a DSL inherently, it is just harder to get right. Maybe Nix does (judging by its popularity. I haven’t used it enough to judge), but in general, package manager DSLs never end up better except for a subset of cases.
What are those 16 standards? I haven’t heard of this before but it sounds interesting!
Although this XKCD is funny, I do not agree with its premise. The presence of many competing standards is usually due to some underlying issue or due to a good reason.
For example, the competing standards in package management is more due to distributions reinventing their own implementation of doing almost the same thing. Debian and Fedora, for example, aren’t doing anything drastically different. Moreover, they don’t make it easy to use outside of their systems.
Any configuration coded in, for example, Python 3.12, will cease to be useful in October of 2028, when it will become quite difficult to find an active useable Python 3.12 runtime.
https://endoflife.date/python
Whereas the same configuration, in an Ansible Playbook, will likely continue to function just fine, under the latest Anbile and Python versions.
I’ve experienced this rodeo enough times that I trust Domain Specific meta-languages much more than direct program code, for configuration.
On the XKCD, yeah. It’s a joke. Randal Munroe isn’t actually advocating to stop trying to fix our standards.
I refer to it here as a reminder that there will always be fatigue with each new RFC, and that’s okay.
Also, not every RFC will turn out as timeless and eternally useful as RFC 2324 And there’s no excuse for my bringing it up here, except that I like it.