The fundamental problem of programming language package management

Post by davexunit » Tue, Aug 26, 2014, 1:53 PM UTC

bad_user wrote: post #12

davexunit wrote: post #6

Earlier quoted context omitted.

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…

You could of course use a platform that doesn't depend on OS dependent binaries (like the JVM) and a package manager that likes ad-hoc and easily created repositories and that has lots of plugins available (Maven, or derivates like Gradle, SBT or Leiningen). I worked with a lot of platforms, such as PHP, Perl, Ruby, Python, Node.js and .NET. I felt the pain of pip, easy_install, setup-tools, virtualenv, bundler, gems…

Post by calpaterson » Tue, Aug 26, 2014, 2:20 PM UTC

mrottenkolber wrote: post #27

calpaterson wrote: post #3

The 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 t…

> Dealing with multiple library changes at once is an order of magnitude more difficult than dealing with them one-at-a-time. From my experience exactly the opposite is true. Compare uprading Slackware to keeping an Arch Linux running. With Slackware, I have to sit down for an hour, do the upgrade, read the notices that come along with it, maybe see if it will break any of my custom packages. This happes once or twic…

Post by jberryman » Tue, Aug 26, 2014, 2:22 PM UTC

pkolaczk wrote: post #32

Just by reading the title I expected this would be about fixing the dependency diamond problem. I.e. when library A needs library C 1.0 and B needs library C 1.1 incompatible with C 1.0 and then libraries A and B meet in the same project :(

Post by elwin » Tue, Aug 26, 2014, 2:32 PM UTC

bad_user wrote: post #8

davidgerard wrote: post #5

Every 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.

Post by 1_player » Tue, Aug 26, 2014, 3:16 PM UTC

chrisfarms wrote: post #2

Nix, 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…