re: What are your thoughts on multiples package managers? VIEW POST

TOP OF THREAD FULL DISCUSSION
re: Well most of these package managers are for devs so I like the fact they are separate from each other, they can move and iterate faster. I remember...
 

That's a fair point. And of course having separate package managers is convenient for devs but I still think that a way to aggregate all those packages into one place (like a meta package manager that would wrap the others) could be a nice thing. Or simply a way to integrate "external" packages with the distributions' package manager, something like the manual .deb installation on Debian-based distros or the AUR repo on Arch.

 

I still think that a way to aggregate all those packages into one place (like a meta package manager that would wrap the others) could be a nice thing.

It means someone has to start a project, write a "facade" on all (or at least the major package managers) with commands like topmtrta npm search react which translates to npm search react (because if it searches on all of them you have to wait 15 seconds :D), track all the changes these package managers implement so that you can keep your facade up to date and so on.
It seems like a slog for not that much gain. What happens if you type topmtrta install react and both npm and pip and gem and cargo have a package with the same name :D ? I'm sure if we think hard about it we can find a lot of use cases that probably make the meta package manager a daunting task. If this tool requires the dev to actually know the commands of the underlying package system then they will end up using the native one anyway.

Or simply a way to integrate "external" packages with the distributions' package manager, something like the manual .deb installation on Debian-based distros or the AUR repo on Arch.

That's not that different from having distro specific packages in the first place though.

Keep in mind that most of this package manager exist also because communities around a specific language don't want to track all the different variations of linux distros or deal with the host system more than they have to. They usually install stuff in the home directory so it doesn't conflict with the host operating system and they just change a couple of env variables to make the magic work.

ps. topmtrta means "the one package manager to rule them all" and it's copyrighted since two seconds ago :P

Of course it would be a daunting task, and to be honest, creating a new package manager to solve the "too many package managers" issue is kinda dumb. That reminds me of this:

But I think it's important to make a difference between a dev package and a end-user package. Dev packages are updated often and should be installed quickly with ease, for this, languages' package managers are neat. But using them to install end-user softwares seems more like lazyness (they just don't want to package a .deb and a .rpm) than anything else.

Got it, but isn't end user software already packaged by distros? Command line tools are not exactly end user software, unless the end user is a technologist who would know how to operate a command line anyway...

LOL at the xkcd strip, so true

code of conduct - report abuse