Hacker News new | comments | show | ask | jobs | submit login

Yawn, another language-specific package manager.

If only there was something like a universal package manager, that provides a generic but powerful package-management platform. Something where package specifications look just like expressions in a purely-functional programming language, and the package manager implicitly understands the complete dependency graph, including all inputs to all build actions.

Something like Nix.




> Yawn, another language-specific package manager.

People have been bemoaning language-specific package managers in favor of (Nix/apt-get/yum/Homebrew/MacPorts) for years now, and again and again developers keep flocking to them, despite the supposedly-superior alternatives being readily available. Rather than continuing to complain about this state of affairs, perhaps we should try to figure out why language package managers are so successful.


Nix is far different than everything else you mention. It's not tied to a particular Linux distribution or OS (well, Windows/Cygwin support is shaky but nobody is stopping you from improving that). It provides a foundation (functional package management) unlike any other package manager (except Guix), which solves and allows you to solve many problems that are inherently unsolvable in other PMs (just read the docs ;).

The reason people keep flocking to the favorite language-specific package manager is that it is seemingly the easiest way to solve their immediate problem - get the dependencies installed so they can get on with coding. And the reason not many people go with Nix is first they don't know about it, second it initially seems scary, third the particular package they need may not yet exist.


I can think of at least 2 advantages.

1. only packaging once, opposed to making a .deb, a .rpm and so on.

2. as soon as its in the language repo, it's available everywhere. Even if I make an apt-get package, I'd have to wait for Ubuntu/Debian/others to include it in their repos. Or I'd have to host a ppa, requiring users to search for it and add it to their package manager. RPM fusion and AUR simplify that, but it still seems hard to have your own packages on .deb systems.


Also because people are complacent with something that works well most of the time, but not all of the time. (where most applies only if you're running the latest stable Ubuntu)


I think it is backwards logic to cite the popularity of Cargo as validation of language-specific package management, when Cargo was officially blessed by the Rust devs:

http://blog.rust-lang.org/2014/11/20/Cargo.html

Standardizing on Cargo as a build system and package manager was a massively important technical decision that was made by the Rust devs. It will have positive and negative consequences for the language, probably for as long as it is relevant.

Rust will work really well with other rust code thanks to Cargo, but what if you want to make a complex project that mixes Rust with other languages at the package level? How about inside of one library? Rust isn't any worse than other languages on this front, but it could have been way better.


Can you elaborate on how Rust "could have been way better"? IME Rust interoperates fantastically with other languages, both as a component in foreign codebases and with foreign languages embedded in Rust libraries.


If only there was something like a universal package manager, that provides a generic but powerful package-management platform.

OK, I like where you're going...

Something where package specifications look just like expressions in a purely-functional programming language, and the package manager implicitly understands the complete dependency graph, including all inputs to all build actions.

No, you lost me.

Look, Nix and Guix are really great ideas, I don't debate that, but they are not what people want.

People who design and build tools want them to be interesting, but people who use tools want them to be boring. They want them to be boring because boring things present the least resistance

What people want is exactly the first thing you said. They want a package manager that does the things that npm and bundler and pip+virtualenv and cargo and everything else do, but works for all languages and across all platforms, and also provides the functionality of a system package manager.


>What people want is exactly the first thing you said. They want a package manager that does the things that npm and bundler and pip+virtualenv and cargo and everything else do, but works for all languages and across all platforms, and also provides the functionality of a system package manager.

But Guix and Nix provide exactly this. They just need to be ported to more platforms and processor architectures. Language-specific packages all have giant flaws like not being able to handle dependencies that aren't packages for that language such as C shared libraries, or duplicating dependencies on disk for each project bundle, or relying upon a single point of trust without the option to build from source, non-reproducible builds, non-precise package specifications (loose versioning), etc.

Nix and Guix come with tools that act as a language-agnostic virtualenv called nix-shell and 'guix environment', respectively. For example, if a Guix user wants to build Emacs from source, they can spawn a shell with all of the needed dependencies with 'guix environment emacs' and move on with their lives. It can't get much more boring than that. This is precisely what I want as a user of a package manager: To spend less time worrying about dependency management. Nix and Guix, using the functional package management paradigm, are the only projects that offer it.


Until you have to write a recipe...


You can have inline shell scripts. You just need to know the names of the phases to override, and the implied environment variables like $out. Not very much harder than writing other recipes.


... And then it's much easier than writing package recipes for other package managers.



"Language-specific"? It clearly targets two languages: C and C++.


> "Language-specific"? It clearly targets two languages: C and C++.

So it's specific to C and C++ (and, apparently, also Go). How is that not Language-specific?




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: