6 ms·

There is a natural break between system-level package management and language-level package management. If you install language-level packages with system-leve

There is a natural break between system-level package management and language-level package management. If you install language-level packages with system-level package managers, then each language package needs to support every single system-level package manager. E.g. you write a Ruby package and now you have to support apt-get, yum, Gentoo, Arch, brew, MacPorts, etc. This is a completely ridiculous situation to put language developers in, especially since most language-level packages don't care what system they run on. Instead, the best practice seems to be to install programming languages with the system-level package manager and install the language's packages with the language-level package manager. That way you only need one system-level package per language, and each language-level package only needs to deal with that language's package manager. The system package manager is responsible for dealing with system-specific things while the language package manager is responsible for language-specific things. It's a natural division. It is conceivable that there could be a single cross-language, language-level package manager. But what language would it be written in? And how would it deal with the fact that each language uses different technologies and has different approaches for installing and configuring libraries and packages? When you think about it for a bit, I don't think it's so insensible for each language to have its own package manager.

Hello71 12y ago
> you write a Ruby package and now you have to support apt-get, yum, Gentoo, Arch, brew, MacPorts, etc wrong. that's the package maintainer's job. moreover, sensible package management systems have templates or libraries (eclasses in Gentoo) to properly handle all kinds of packages. all we ask for is that developers don't actively break package management by bundling everything as is done here.
- voltagex_ 12y ago
  Ir seems like there is often a breakdown in communication between upstream and distro package maintainers. It may also be that authors don't have time to talk with ~3 (Debian, Fedora, ???) distros, each with different packaging processes and rules.
- drewcrawford 12y ago
  Distro packages don't solve the needs of software developers. They solve the need of distros, which are different (and conflicting) with the needs of software developers. Therefore you will always have an eternal struggle between language-level package managers who work for developers and system ones that work for distros. If there was some simple way to lob a tarball over the wall and get package inclusion on Debian, Fedora, Gentoo, etc., then that would be one thing. In reality however the number of random GitHub repos >> the number of package maintainers. I know that Debian uses a variety of technical and social methods to discourage new packages, and most people's software just isn't popular enough to overcome those barriers, even if some of the reason they're not popular is because they're not well-packaged (sort of a catch-22 there). Not to mention people who install via apt or rpm are perpetually out of date. Now compare that with pip or rubygems--one package to maintain, installs more-or-less everywhere, accepts packages regardless of popularity, end users are more often up-to-date. Better for software developers' problems in every single dimension. Sure that's bad for Fedora maintainers, but what are Fedora maintainers doing for me?
  - Hello71 12y ago
    > Sure that's bad for Fedora maintainers, but what are Fedora maintainers doing for me? ensuring a myriad of things that individual developers simply don't seem to care about, ranging from simple testing to inter-package compatibility to licensing to init scripts to old package cleanup to unbundling to...
- StefanKarpinski 12y ago
  Your view assumes that all language-level packages are already so mature that each of Debian, Gentoo, Arch, brew, MacPorts, etc. have a person whose responsibility it is to make a system-level package for that language-level package. What about new packages? If language packages are to be distributed on each system using the system package manager, then the way to get a new package into the hands of programmers is to a) write the package and b) before anyone has used it, spend a couple of years convincing a person on each system to create and maintain a system package for this new and completely unused Ruby/Python/Perl package. I guess that's reasonable if you're dead set on only using software that was written ten years ago.
michaelmior 12y ago
It seems like a reasonable task to create a package manager which is able to interface with the "standard" package management tools for a particular language to avoid the need to worry about the details of each tool. I'm not sure if I'd use such a tool myself, but I could imagine some would find it useful and it doesn't seem like it would be a huge challenge to create.
endgame 12y ago
The smartest way to do it is to have everyone's special snowflake languages support automake. Because automake's tarballs are so common in the free software world, every package manager has special support to make packaging them easy (cdbs, eclasses, ...). Then when you need something for yourself, you can go get it from an overlay (layman is the thing I miss most about gentoo), ppa or quickly roll up a package yourself.
microcolonel 12y ago
The way this works is that the system-level packages handle setting up the metadata for the language's module system, either through files or install-time scripts, and the language package itself handles the rest. This is how it works in Python, Perl, Ruby, Guile, and even Emacs on at least Debian(and derivatives such as Ubuntu), Fedora (and derivatives such as RHEL, CentOS, Oracle Linux, and a couple others), Arch, and some others I won't bother to mention. It doesn't matter whether you're using DPKG/APT, RPM/YUM/DNF, ALPM/Pacman, or whatever, the logic is handled in what files are in the package. In a world where systems have decently-functional package managers of their own, there is no need for a language-specific package manager. Language level package managers exist because on major desktop and workstation platforms, system package managers have failed.(OS X and Windows both have several broken, incomplete package managers; none of them are installed by default.) The fact that this got upvoted so heavily is not surprising, given that judging by the current frontpage of HN, much of the userbase doesn't even know ^R does reverse interactive search in most terminals since the '80s.
- kryptiskt 12y ago
  System package managers conflate the stuff that is needed to run the system and what the developer builds with. They do badly in handling several different versions of libraries, they add latency of up to two years and only a subset of the packages are available. And when you are done you have to uninstall all the crap you installed instead of just blowing away the virtualenv (or whatever mechanism the language has).
  - microcolonel 12y ago
    Of course, you don't actually need to uninstall all the crap, because when you install it only once on the system, you don't need to build thirty virtualenvs with roughly the same packages. Also, choosing system package archives is simple. If you want two-ish years of stabilization for a feature release, and you want bugfixes for two or three years or longer, you can go with Debian. If you pull most things off of head anyway then go with Arch. Of course, you're entitled to liking egocentric dependency resolution(or no dependency resolution at all, as practised by most), and I'm not going to stop you. But it really is very convenient and robust to handle high-level language libraries in a system package manager, it helps immensely when you intend to actually ship a piece of software rather than fapping off a script that some poor sap will need to update to patch five-year-old known remote vulnerabilities.

Hello71 12y ago

> you write a Ruby package and now you have to support apt-get, yum, Gentoo, Arch, brew, MacPorts, etc wrong. that's the package maintainer's job. moreover, sensible package management systems have templates or libraries (eclasses in Gentoo) to properly handle all kinds of packages. all we ask for is that developers don't actively break package management by bundling everything as is done here.

voltagex_ 12y ago
Ir seems like there is often a breakdown in communication between upstream and distro package maintainers. It may also be that authors don't have time to talk with ~3 (Debian, Fedora, ???) distros, each with different packaging processes and rules.
drewcrawford 12y ago
Distro packages don't solve the needs of software developers. They solve the need of distros, which are different (and conflicting) with the needs of software developers. Therefore you will always have an eternal struggle between language-level package managers who work for developers and system ones that work for distros. If there was some simple way to lob a tarball over the wall and get package inclusion on Debian, Fedora, Gentoo, etc., then that would be one thing. In reality however the number of random GitHub repos >> the number of package maintainers. I know that Debian uses a variety of technical and social methods to discourage new packages, and most people's software just isn't popular enough to overcome those barriers, even if some of the reason they're not popular is because they're not well-packaged (sort of a catch-22 there). Not to mention people who install via apt or rpm are perpetually out of date. Now compare that with pip or rubygems--one package to maintain, installs more-or-less everywhere, accepts packages regardless of popularity, end users are more often up-to-date. Better for software developers' problems in every single dimension. Sure that's bad for Fedora maintainers, but what are Fedora maintainers doing for me?
- Hello71 12y ago
  > Sure that's bad for Fedora maintainers, but what are Fedora maintainers doing for me? ensuring a myriad of things that individual developers simply don't seem to care about, ranging from simple testing to inter-package compatibility to licensing to init scripts to old package cleanup to unbundling to...
StefanKarpinski 12y ago
Your view assumes that all language-level packages are already so mature that each of Debian, Gentoo, Arch, brew, MacPorts, etc. have a person whose responsibility it is to make a system-level package for that language-level package. What about new packages? If language packages are to be distributed on each system using the system package manager, then the way to get a new package into the hands of programmers is to a) write the package and b) before anyone has used it, spend a couple of years convincing a person on each system to create and maintain a system package for this new and completely unused Ruby/Python/Perl package. I guess that's reasonable if you're dead set on only using software that was written ten years ago.

michaelmior 12y ago

It seems like a reasonable task to create a package manager which is able to interface with the "standard" package management tools for a particular language to avoid the need to worry about the details of each tool. I'm not sure if I'd use such a tool myself, but I could imagine some would find it useful and it doesn't seem like it would be a huge challenge to create.

endgame 12y ago

The smartest way to do it is to have everyone's special snowflake languages support automake. Because automake's tarballs are so common in the free software world, every package manager has special support to make packaging them easy (cdbs, eclasses, ...). Then when you need something for yourself, you can go get it from an overlay (layman is the thing I miss most about gentoo), ppa or quickly roll up a package yourself.

microcolonel 12y ago

The way this works is that the system-level packages handle setting up the metadata for the language's module system, either through files or install-time scripts, and the language package itself handles the rest. This is how it works in Python, Perl, Ruby, Guile, and even Emacs on at least Debian(and derivatives such as Ubuntu), Fedora (and derivatives such as RHEL, CentOS, Oracle Linux, and a couple others), Arch, and some others I won't bother to mention. It doesn't matter whether you're using DPKG/APT, RPM/YUM/DNF, ALPM/Pacman, or whatever, the logic is handled in what files are in the package. In a world where systems have decently-functional package managers of their own, there is no need for a language-specific package manager. Language level package managers exist because on major desktop and workstation platforms, system package managers have failed.(OS X and Windows both have several broken, incomplete package managers; none of them are installed by default.) The fact that this got upvoted so heavily is not surprising, given that judging by the current frontpage of HN, much of the userbase doesn't even know ^R does reverse interactive search in most terminals since the '80s.

kryptiskt 12y ago
System package managers conflate the stuff that is needed to run the system and what the developer builds with. They do badly in handling several different versions of libraries, they add latency of up to two years and only a subset of the packages are available. And when you are done you have to uninstall all the crap you installed instead of just blowing away the virtualenv (or whatever mechanism the language has).
- microcolonel 12y ago
  Of course, you don't actually need to uninstall all the crap, because when you install it only once on the system, you don't need to build thirty virtualenvs with roughly the same packages. Also, choosing system package archives is simple. If you want two-ish years of stabilization for a feature release, and you want bugfixes for two or three years or longer, you can go with Debian. If you pull most things off of head anyway then go with Arch. Of course, you're entitled to liking egocentric dependency resolution(or no dependency resolution at all, as practised by most), and I'm not going to stop you. But it really is very convenient and robust to handle high-level language libraries in a system package manager, it helps immensely when you intend to actually ship a piece of software rather than fapping off a script that some poor sap will need to update to patch five-year-old known remote vulnerabilities.