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.
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?
> 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...
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.
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.
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.
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).
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.
Hey, until recently (about 6 months ago) I didn't even know about <Alt>+<.> either.
It's not until you start using this stuff on a daily basis that you start discovering these things.
Not everyone has been using Linux for long. Frankly, I consider myself pretty much a Linux noob. I'm a spoiled Windows brat, who only recently started transitioning to Linux (now Linux is the one spoiling me, but that's besides the point).
This is the primary reason why I come to HN anyway. To learn. :-)
In many/most shells (bash) it inserts the last word of the last line at the position of the cursor. It's very handy when you want to do two or more things to the same file because you don't have to retype the name, just hit alt-..
On Windows, I may install pywin32 at system level, but I need a virtualenv with different versions of requests [1] for different projects.
For .NET, NuGet is the only game in town - decent dependency resolution, a good package selection and if you do things right, no binaries stored in source control (except eleventy copies of NuGet.exe but I don't think they can fix that bad decision now...)
Even on Debian I might go with a virtualenv or rvm because I don't necessarily want users to have to apt-get a whole lot of stuff just to run a simple script.
>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.
That worries me too, but then I remember I don't have a clue about the functional programming articles that turn up here. It all balances out in the end.
There may be a fair few people here who are making the shift from GUIs to CLIs for the first time, so it may not be a bad thing.
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.
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.
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.