I just came to realize: I once loved Linux for one (of many) thing: the fact that everything was installed using a centralized package manager. Com...
For further actions, you may consider blocking this person and/or reporting abuse
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 back in the day how much you had to wait for a piece of software to be approved by the Debian team :D
Also the OS teams can't possibly be on par with every package, every language that pops up and so on.
brewis a good measure, you can use it to install dev tools, "regular" software and with cask even manage binaries.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.
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 reactwhich translates tonpm 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 reactand 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.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.
topmtrtameans "the one package manager to rule them all" and it's copyrighted since two seconds ago :POf 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
And let's of course not forget this one =)
loool
I think npm, pip and the like are great for distributing dev packages because I might need to have different versions for different projects and many stuff I don't want to install system wide.
However, I don't like when end user applications are distributed through one of those package managers, I'd rather have them available through the OS package manager.
Agreed, for dev dependencies it's a very nice thing.
Arch Linux's package management ecosystem is a big part of why it's my favorite general-purpose distro. Anyone can create a package for the Arch User Repository (AUR) assuming the name hasn't been taken, and there are "AUR helpers" which wrap the built-in package manager (pacman) to download and install packages from both the official repos and the AUR. Popular AUR packages can be moved into the official repos as well. I've written my own AUR packages, for example to install the hostess hosts file management tool.
I still use other package managers for dependency management: npm, Maven, occasionally pip, gem and bundler, cpanm, pgxnclient. But I try to avoid installing tools through them.
Apparently I discover tools through your comments :D ripgrep and now hostess.
Yeah, that's the one reason why I miss Arch (I used it for a while but came back to Debian), AUR has pretty much everything.
To be honest, I'm a little frustrated with how many package managers are out there - I understand the problem, but if there's a program I want to try that requires me to use a package manager I'm not super familiar with, I often won't bother. I guess this is a point in favor of programs written in Go or Rust, or those that are easy to statically compile. This mostly applies to a program I read about that I want to try out - once a tool has proven its value, I'll package it up myself if need be!
That being said, I don't mind npm or pip so much, mainly because
node_modulesstays local to whatever directory I'm working in (I never use-g), and I can easily create a virtualenv, so I can try out new JavaScript or Python tools pretty painlessly. (I'm betting other language-level package managers have something similar, but I haven't take the time to learn about them!)Looking at other comments to this thread, I see a lot of mention of Linux package managers - I think an interesting approach could be to a) allow non-root users to install packages under a certain directory (eg. why shouldn't I be able to install a package whose contents lives under
~?) - I think Fedora was working on this?, and b) to have a mode for language-level package managers to integrate with this functionality. So, to take npm and Arch's pacman as an example, npm could tell pacman "hey, I installed these files as part of thefoopackage", and pacman could write an entry in its local package database fornpm/foo. After all, the point of a lot of packaging build scripts likePKGBUILDis to essentially build a package tarball with a little metadata; why couldn't a tool provide that metadata and its own archive structure instead?Even with that in mind, I think we might not see work going into that - now that containerization is taking off, the mindshare seems to be going into packaging up application as snaps or even full Docker containers.
Anyway, sorry for the rant - I just got really into thinking about this!
I prefer to have all of my stuff in a single place, so I usually opt to install everything I can through my system's package manager. This way I can update all my software and libs in a single step.
The only exception to that is when handling actual source code for libraries that won't be used system-wide, for which I prefer to use the language's own manager, like Rust's Cargo.
Yeah but installing with the system's package manager is not always an option, there are a lot of distributions where packages for some softwares are outdated or don't even exists.
On Windows, I have a similar problem: Most software can be installed through Chocolatey - but some just isn't there. Also, each language comes with its own package manager, except C where I really would like to have one... :(
That's exactly why I haven't tried Chocolatey yet, I guessed it would feel... incomplete. And I mostly use Windows for gaming anyway, so I don't install much things and don't care much about keeping it clean.
Well, if you want a package manager for C, just use a Linux OS, most C libs are distribution packages 😋