The fundamental problem of programming language package management
1–10 of 73 posts
Re: The fundamental problem of programming language package management
#2Nix, NixOS, Nix ... a thousand times Nix.
I can't believe the article doesn't mention it.
I've been using NixOS as my OS for development, desktop and we're in the middle of transitioning to using it for production deployments too.
Nix (the package manager not the distribution) solves so many of the discussed problems. And NixOS (the linux distribution) ties it all together so cleanly.
I keep my own fork of the Nixpkgs repository (which includes everything required to build the entire OS and every package), this is like having your own personal linux distribution with the but with the simplest possible way of merging changes or contributing from upstream.
I use it like I'd use virtualenv. I use it like I'd use chef. I use it like I'd use apt. I use it like I'd use Docker.
Re: The fundamental problem of programming language package management
#3The downside he mentions to "pinned versions" actually applies to everything on this page. If you don't pay attention to security updates, you will be vulnerable whether or you forgot about your pinned versions or you forgot about your stable distribution.
"Stable" distributions have an additional downside he doesn't mention: when you upgrade every package all at once it's a LOT more effort than if you had upgraded them slowly over time. Dealing with multiple library changes at once is an order of magnitude more difficult than dealing with them one-at-a-time.
And also, to some extent, if all the libraries you are using have a long term stable API, then it doesn't actually matter which one you pick - anything is painless.
Re: The fundamental problem of programming language package management
#4yeah yeah, I read the previous post (http://www.standalone-sysadmin.com/blog/2014/03/just-what-we...) too.
Maybe this time we can talk about how to meaningfully solve these problems instead of just fighting pointlessly about if old tools are so great should be used for everything.
Decentralized package management huh?
How would that work?
A way of specifying an ABI for a packages instead of a version number? A way to bundle all your dependencies into a local package to depend on and push changes from that dependency tree automatically to builds off of it, but only manually update the dependency list?
I'm all for it. Someone go build one.
Re: The fundamental problem of programming language package management
#5Every program with plugins of any sort will eventually include a sketchy rewrite of apt-get. Not just languages - WordPress, MediaWiki ...
If you're very lucky, the packaging in question will not conflict horribly with apt or yum. So you probably won't be lucky.
Re: The fundamental problem of programming language package management
#6Nix, NixOS, Nix ... a thousand times Nix. I can't believe the article doesn't mention it. I've been using NixOS as my OS for development, desktop and we're in the middle of transitioning to using it for production deployments too. Nix (the package manager not the distribution) solves so many of the discussed problems. And NixOS (the linux distribution) ties it all together so cleanly. I keep my own fork of the Nixpkg…
Yes! The Haskell community has been using Nix to great effect and I would like to see other programmers catch on as well. Here is a great talk about using Nix targeted at Python programmers: http://pyvideo.org/video/3036/rethinking-packaging-developme...
In addition to Nix, there is also a newer project: GNU Guix. Guix is built on top of Nix but replaces the custom package configuration language with Scheme, among other differences. https://gnu.org/software/guix/
When package management is solved at the system level, our deployment situation becomes a whole lot better. I used to do a lot of Ruby programming. Wrestling with RVM and bundler was a real pain, especially since bundler was incapable of helping me with the non-Ruby software that I needed as well like libmysqlclient, imagemagick, etc. Using Nix/Guix, you can throw out hacky RVM (that overrides bash built-ins like cd!) and simply use a profile that has the right Ruby version.
Bye pip, bundler, composer, CPAN, puppet, ansible, vagrant, ..., and hello Nix/Guix!
Re: The fundamental problem of programming language package management
#7yeah yeah, I read the previous post ( http://www.standalone-sysadmin.com/blog/2014/03/just-what-we... ) too. Maybe this time we can talk about how to meaningfully solve these problems instead of just fighting pointlessly about if old tools are so great should be used for everything. Decentralized package management huh? How would that work? A way of specifying an ABI for a packages instead of a version number? A way…
> A way of specifying an ABI for a packages instead of a version number?
Technically impossible for many languages (have fun figuring out what it would look like in Perl...). And even when it's possible, it's not a guarantee: you can have a semantic change without an ABI change. Cargo, Rust's newfangled package manager, supposes semantic versioning, and I think it's a sane attitude.
Re: The fundamental problem of programming language package management
#8Every program with plugins of any sort will eventually include a sketchy rewrite of apt-get. Not just languages - WordPress, MediaWiki ... If you're very lucky, the packaging in question will not conflict horribly with apt or yum. So you probably won't be lucky.
As if apt-get would solve the problems that we have. Good luck in installing multiple versions of the same package with apt-get.
Re: The fundamental problem of programming language package management
#9Nix, NixOS, Nix ... a thousand times Nix. I can't believe the article doesn't mention it. I've been using NixOS as my OS for development, desktop and we're in the middle of transitioning to using it for production deployments too. Nix (the package manager not the distribution) solves so many of the discussed problems. And NixOS (the linux distribution) ties it all together so cleanly. I keep my own fork of the Nixpkg…
Yes! The Haskell community has been using Nix to great effect and I would like to see other programmers catch on as well. Here is a great talk about using Nix targeted at Python programmers: http://pyvideo.org/video/3036/rethinking-packaging-developme... In addition to Nix, there is also a newer project: GNU Guix. Guix is built on top of Nix but replaces the custom package configuration language with Scheme, among ot…
> In addition to Nix, there is also a newer project: GNU Guix. Guix is built on top of Nix but replaces the custom package configuration language with Scheme, among other differences. https://gnu.org/software/guix/
Personally, I'm rather more keen on Nix; the language is pretty much designed for writing JSON-style configuration except as a formal programming language, which is what the vast majority of Nix code is (both package definitions and system configurations).
Additionally, with Nix, you can be close to certain that if you build something twice, you'll get the same result, because it can't access impure resources.
Finally, because Guix is a GNU project, the official repositories are going to go nowhere near non-free software. Nixpkgs contains non-free software, although disabled from installation by default. You might be a little less likely to have people help you get non-free software working on the GNU Guix mailing lists, if you happen to use any.
Re: The fundamental problem of programming language package management
#10Every program with plugins of any sort will eventually include a sketchy rewrite of apt-get. Not just languages - WordPress, MediaWiki ... If you're very lucky, the packaging in question will not conflict horribly with apt or yum. So you probably won't be lucky.
As if apt-get would solve the problems that we have. Good luck in installing multiple versions of the same package with apt-get.
Yes, there's that too.