Hacker News Reader

Comment by bluGill | Hacker News Reader

I firmly believe that languages should not manage packages. While it makes the simple cases easy for beginners, the trade off is mixing languages becomes harder. There is no perfect language and often mixing should be the right answer and we don't want any more friction there.

View on HN

Who then? Distros? One of my favorite software engineering comics is "User Friendly" from 1999: https://distrowatch.com/images/other/userfriendly-comic.png

Yep. Package management is the core of a (Linux) software distribution.

I thought the current process was just to herpderp it and put everything into a container.

I hope that fad dies. It assumes all the world is x86-64 Linux. Maybe you get a few who acknowledge the raspberry pi. However there is a whole world of new other processors, *BSD, and others that the fad makes difficult to use.

Linux package management is already fragmented, the last thing we should do is add programming languages package management to it.

Nobody that currently exists - at least to my knowledge. This is a hard, mostly thankless problem. Distros solved a similar problem, but they have different motivations and so didn't fully solve everything. Languages like rust have a partial solution, but they don't play well with other languages and the full complexity that can result.

I quite agree! And would it even be harder for beginners? When trying a new a program written in a language I don't use frequently, I usually spend a good half-hour working out what command to run to install the dependencies and going through the logs working out what implicit requirement wasn't in the README. A holistic package, even one written for a different software distribution than the one I use (Debian at present), would immediately get me 99% of the way there.

PS. If you find yourself in the same situation I do, Repology is your friend: https://repology.org/

I do believe this is an issue of not having explicit dependencies. Julia takes the approach of, we build and ship everything for every OS, which means Pkg (the package manager) knows about binary dependencies as well. Making things more reproducible in language

Linux distros often do things to force packages to declare all their dependencies: Nix and Guix use unique prefixes and sandboxed builds, openSUSE builds all their packages in blank slate VMs that only install what is declared, standard Fedora tools for running builds in minimal chroot environments, etc.

I'm not aware of any language ecosystem package managers taking similar measures to ensure that dependency declarations in their packages are complete.

The problem with system packaging is there are so many systems. For example if you only package something for Debian, how should a Fedora, Arch, Gentoo or even Mac and Windows user use that?

The problem with systems packages is they solve a slightly different problem from language packages, and so while they are closer to what is needed, they are not right either.

That is one reason I didn't specify the solution.

Debian has by far the most rigorous packaging standards of that list, so subsequent packaging for the other distributions should not be very difficult. Bundling the dependencies into an OCI container or AppImage to run them on non-Debian systems is also trivial once you have a Debian package, but of course that comes with disadvantages. Neither Mac nor Windows have a proper first-party package manager (although winget makes some inroads, thanks of course to Keivan Beigi), so comparison becomes rather a moot point for those platforms.

[1]: https://keivan.io/the-day-appget-died/

"so comparison becomes rather a moot point for those platforms."

No, because the OP was comparing them to language package managers, which are widely supported on Windows

Parent said that the "problem with system packaging is there are so many systems" - emphasis mine.

This really holds back languages and libraries.

Trying to release libraries and language upgrades when you have to worry about different versions.

One of the reasons Rust has been able to move so rapidly is that it is not dependent on system packagers.

Agreed. It's unbelievable to see all these languages inventing packaging over and over again. It's just an archive with some metadata and a hash/signature and a transport mechanism.

Reply on news.ycombinator.com