[Nix-dev] Stackage Support Will Be Discontinued

[Anthony Cowley]

Peter Simons writes:

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

I truly don't understand why this is hard for you to understand, so we are of a mind on this misunderstanding! There must be a language barrier or different understanding of what breaking version changes are between us.

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

I think that telling users to stick to a single version of nixpkgs and take responsibility for cherry-picking individual security and bug fix commits to all Haskell and system libraries they depend on is the worst job a package management system can do while still calling itself a package manager. I do appreciate that you find such a setup appealing, so I'll say no more as this is solely your call.

Anthony