[Nix-dev] Stackage Support Will Be Discontinued

Peter Simons simons at nospf.cryp.to
Thu Jun 9 23:04:40 CEST 2016


Hi Anthony,

 >> [What is] a concrete use case that works for you today but that
 >> won't work after LTS-4 has been dropped?
 >
 > Someone who has a project that works with package versions in LTS-4,
 > but hasn't yet been upgraded to LTS-5 or 6. They can simply refer to
 > LTS-4 in their shell.nix for haskell packages.

Oh, but you can absolutely do that! You can extend the set of available
packages to your heart's content and you can compose package sets that
provide any combination of versions as you please. The Haskell
infrastructure in Nix gives you that ability.


 >>> You are removing that opportunity because it hasn't been used yet.
 >>
 >> I don't intend to remove any "opportunities" here. All I want to remove
 >> is some 850,000 lines of untested, unmaintained code from the Nixpkgs
 >> repository. [...]
 >
 > If it's 850,000 lines of code, then that really seems like a Nix
 > issue. If the point here is to declare bankruptcy and tell people to
 > use stack which is able to refer to multiple versions of packages,
 > then let's call it that.

I have a hard time assigning meaning to vague terms like "removing
opportunities" and "declaring bankruptcy" in a technical conversation. I
am sorry, I just don't see how to these kind of things make a compelling
argument for distributing old LTS releases in Nixpkgs.


 > [A team using Nix today] can refer to LTS-5 in nixpkgs, and not need
 > to make any changes to adopt LTS-6 until they are ready. I know that
 > should a problem emerge with LTS-5, a project using stack has a good
 > chance of benefiting from a new Stackage release. I know that after
 > the changes you are making, the team using LTS-5 in nixpkgs will not
 > have a working environment until they address any of the 5->6
 > breaking changes.

This is true only if we assume that the team depending on LTS-5 updates
their copy of Nixpkgs to a version that breaks their code. But they
don't have to. They can use a version of Nixpkgs that works for them
until they're comfortable addressing the issues caused by an update.
Also, these changes I'll be making show up only in the branch we dub
"unstable". The release-16.03 branch, for example, has LTS-5 and will
continue to have it until all eternity.

You realize that Nix allows you to override the contents of the Nixpkgs
version you're using without actually editing that version, right? You
can stick to any given version of Nixpkgs, but if an update of, say
libuuid, comes out that you'd like to have, then you can override only
that particular package in configuration.nix or ~/.nixpkgs/config.nix
without ever touching Nixpkgs itself. This gives you a stable package
plus selected, hand-picked updates. IMHO that is an awesome mechanism
for stable deployments.

Best regards,
Peter



More information about the nix-dev mailing list