Why people keep creating new package managers

March 26, 2014

Matt Simmons recently wrote Just what we need ... another package manager, in which he has an unhappy reaction to yet another language introducing yet another package manager. As a sysadmin I've long agreed with him for all sorts of reasons. Packaging and managing language 'packages' is an ongoing problem and in our environment it also causes user heartburn when we have to turn down requests to install language packages through the language's own mechanisms.

(We have a strong policy that we only install official distribution packages in order to keep our own sanity. This works for us but not necessarily for other people.)

But at the same time I have a lot of sympathy for the language people. Let's look at the problem from their perspective. Languages need:

  • package management everywhere they run, possibly including Windows (which has no native package management system) and almost certainly including the Macs that many developers will be using (which also lack a native packaging system).

  • something which doesn't force package contributors to learn more than one packaging system, because most people won't and languages want a healthy, thriving ecology of public packages. Ideally the one packaging system will be a simple, lightweight, and low friction one in order to encourage people to make and publish packages.

  • for developers of language packages to not have to deal with the goat rodeos and political minefields that are the various distribution packaging processes, because making them do so is a great way of losing developers and not having packages.

  • some relatively handy way to install and update packages that are not in the official distribution repositories. No language can really tolerate having its package availability being held hostage to the whims of distributions because it basically guarantees an out of date and limited package selection.

    (The interests of languages, developers of language packages, and distributions are basically all at odds here.)

  • support for installing packages in non-default, non-system locations, ideally on both a 'per developer' and a 'per encapsulated environment' basis.

From the language's perspective it would be nice if package management for the language could optionally be done the same way regardless of what host you're on. In other words, developers should be able to use the same commands to install and set up packages on their development Macs as they do on testing VMs running some Linux distribution (or even FreeBSD), and possibly also on the production systems.

(In the modern lightweight world many small companies will not have actual sysadmins and developers will be setting up the production machines too for a while. Sysadmins do not like this but it is a reality. And languages are not designed for or used by sysadmins, they are mostly designed for developers, so it is not surprising that they are driven by the needs of developers.)

It's theoretically possible for a language's package system to meet all of these needs while still enabling distribution packages and doing as much as possible with the core distribution packaging system, either explicitly or behind convenient cross-platform cover scripts. However there are plenty of cases (like non-system installation of packages) that are simply not handled by the distribution packaging system and beyond that there are significant difficulties on both the technical and political levels. It is simply much easier for a language to roll its own packaging system.

(Ideally it will support creating distribution packages and using the distribution packaging mechanisms as well. Don't hold your breath; it's not going to be a language priority.)

Written on 26 March 2014.
« The DNS TTL problem
How we wound up with a RFC 1918 IP address visible in our public DNS »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Mar 26 23:37:25 2014
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.