loading...

Dreams of an ideal world: Rethinking package managers

yujiri8 profile image Ryan Westlund ・2 min read

A while ago I published Dreams of an ideal world: Package managers, where I expressed the idea that language package managers (eg. Pip, Cargo), should be used for language libraries rather than the OS package manager. A discussion I had on a mailing list prompted me to reconsider.

The person disagreeing with me described this as the "destructive philosophy brought to Linux by Pip people". They pointed out problems like the duplication of work between package managers and the inability to use all the features of the OS package manager for language libraries, and the separation of the dependency graph: while it's not common (since many modern languages statically link all their same-language dependencies by default), sometimes language packages depend on other things installed (for example, bindings to Qt), and when they're in completely separate systems managed by different tools, there's no easy way to express dependencies between them.

I still see at least two problems with using the OS package manager for language libraries:

  1. They're very often out of date, and for obvious reasons: most maintainers of packages in high-level language ecosystems do not have commit access to distribution repositories, so they rely on distribution maintainers to update their versions - and we all know how unresponsive FOSS maintainers can be.

  2. Each distribution with its own repositories has to have its own port of language libraries. This is somewhat the flipside of the duplication of work between package managers: it's either that, or duplication of work between package repositories. If I publish something on PyPI, it only has to exist there; the maintainers of FreeBSD, Debian, Arch, Fedora, and all the others don't have to know about it for their users to instantly get the latest version.

Ideally we discover/invent a system that allows high-level language packages to be ported to all operating systems without special attention from each OS's maintainers, while allowing dependency relationships between them. Thoughts?

Posted on by:

yujiri8 profile

Ryan Westlund

@yujiri8

I'm a programmer, writer, and philosopher. My Github account is yujiri8; all my content besides code is at yujiri.xyz.

Discussion

pic
Editor guide
 

Personally, I think Homebrew for Linux (formerly Linuxbrew) is not only so far superior to Snap/Flatpak/AppImage it's laughable (yet never mentioned in their goofy holy wars), but probably the closest to splitting the difference between OS package management and up-to-date language library support.

While I have some issues with adding even more dependencies to the /home/ directory (/home/linuxbrew/ to be exact) after loading $HOME down with global NPM packages (please don't run sudo npm install -g), Homebrew for Linux is severely underrated nonetheless.

I will say that having those things installed in /home/linuxbrew/ is nice since I keep /home/ on a separate partition for easily restoring config after clean installs. That means all of my brew installs are still there and still callable (since my $PATH is preserved).

 

Interesting. I'll have to check it out.