4 ms·

Jesus! Another package manager, I don't even want to look at that website before I can think of a single reason of why would anyone want to have a package manag

Jesus! Another package manager, I don't even want to look at that website before I can think of a single reason of why would anyone want to have a package manager for Bash, once I think of a legitimate use case I will go to that website to see what is their offer. But seriously, do we need a package manager for everything [1]? Some time ago I was thinking to create a package manager for package managers, then realized that it was already proposed [2] and that it has no purpose so I desisted on the idea. [1] https://en.wikipedia.org/wiki/List_of_software_package_management_systems https://en.wikipedia.org/wiki/List_of_software_package_manag... [1] https://news.ycombinator.com/item?id=8387137 https://news.ycombinator.com/item?id=8387137

iamdave 10y ago
I'm sure there's a "single reason" the developer rationalizes in their own mind, but I'm fatigued as hell having to make sure I have yet another package manager installed just to get the %thing%. Obligatory xkcd: xkcd.com/927
whichfawkes 10y ago
In fairness though, the "package manager for package managers" functionality is arguably included in your OS package manager. Furthermore, as (e.g.) a node developer looking to share a package with the community, I'd much maintain one package in npm than one for each of Debian, Arch, Redhat, OSX, etc.
- joepvd 10y ago
  You are so right. Which exactly points at the problem: Multiple OS package managers (choose one), and for each language/framework/... that you use, one extra. Which includes headaches for how to handle overlaps between the two. One ought to take into consideration how others are handling these issues, just to ensure you're not alone. I do not have concrete answers, but I firmly believe that it is possible to reduce the mental and practical efforts required for package and dependency management by somehow abstracting and disciplining the current solutions. In this context, Guile and NIX are often named. Their stated goals, however, are generally about reproducibility of builds. Could anyone point me to discussions/documentation that specifically addresses the wildfire of dependency- and package management?
- Annatar 10y ago
  Since creating OS packages for the target OS can be completely automated, the failure to do so is a failure to make the computer do the work and automate the process.

iamdave 10y ago

I'm sure there's a "single reason" the developer rationalizes in their own mind, but I'm fatigued as hell having to make sure I have yet another package manager installed just to get the %thing%. Obligatory xkcd: xkcd.com/927

whichfawkes 10y ago

In fairness though, the "package manager for package managers" functionality is arguably included in your OS package manager. Furthermore, as (e.g.) a node developer looking to share a package with the community, I'd much maintain one package in npm than one for each of Debian, Arch, Redhat, OSX, etc.

joepvd 10y ago
You are so right. Which exactly points at the problem: Multiple OS package managers (choose one), and for each language/framework/... that you use, one extra. Which includes headaches for how to handle overlaps between the two. One ought to take into consideration how others are handling these issues, just to ensure you're not alone. I do not have concrete answers, but I firmly believe that it is possible to reduce the mental and practical efforts required for package and dependency management by somehow abstracting and disciplining the current solutions. In this context, Guile and NIX are often named. Their stated goals, however, are generally about reproducibility of builds. Could anyone point me to discussions/documentation that specifically addresses the wildfire of dependency- and package management?
Annatar 10y ago
Since creating OS packages for the target OS can be completely automated, the failure to do so is a failure to make the computer do the work and automate the process.