[Nix-dev] Stackage Support Will Be Discontinued

[Anthony Cowley]

Peter Simons writes:

> Hi Anthony,
>
>  > I draw a distinction between newer minor versions obsoleting old ones
>  > for purposes of bug fixes vs. for purposes of freezing packages.
>
> I am sorry, but I don't understand that distinction. In your original
> response you suggested that dropping old LTS major releases like LTS-4
> from Nixpkgs would reduce your ability to use Nix, i.e. it would make
> Nixpkgs less useful to you than it is today. I have a hard time seeing
> how what might be the case, so I wonder whether you'd mind explaining to
> me 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.


>  > The Stackage design is such that they *can* release bug fixes for
>  > older versions to help their users.
>
> Yes, I totally agree. Once Stackage starts releasing updates for older
> LTS versions, it's a completely different situation and then carrying
> around older LTS major releases would actually make sense.
>
>
>  > 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 there is a compelling use case for that code, then let's
> talk about it! At the moment, however, the cost / benefit ratio of
> keeping all those package sets around strikes me as bad, really, and I
> don't think we should keep distributing that code unless there's a real
> benefit to the effort.

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.

>  > As companies adopt Stackage package sets, they will have applications
>  > in production that they, A) really want bug fixes for; and B) do not
>  > want to keep on the hackage treadmill by following new releases. If a
>  > bug is found in an LTS-5 package within the next few months, a stink
>  > will be raised.
>
> I think everyone agrees that we *want* LTS-5 updates to come out even
> after the release of LTS-6. Whether that is actually going to happen or
> not, however, is speculation and neither you nor me can possibly know.

I know that today a team using Nix 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.

>  >> In Nix, we [freeze dependencies] by tagging a specific version of
>  >> Nixpkgs and sticking to that. Not only will that freeze the Haskell
>  >> dependencies, but it will also freeze all other dependencies, too.
>  >
>  > This is a big step backwards. You object that Stackage has not yet
>  > used their existing mechanism for releasing bug fixes for older
>  > Haskell libraries, and respond by promoting a mechanism that admits
>  > no bug fixes for any software at all.
>
> I have no idea what you are talking about. Nix offers a myriad of
> different ways to cherry pick updates into a stable version of the
> package set.

Here's a quote that perhaps states it more clearly, "In Nix, we can solve these things by tagging a specific version of Nixpkgs and sticking to that. Not only will that freeze the Haskell dependencies, but it will also freeze all other dependencies, too."

I saw on IRC that you use stack for some Haskell development and nixpkgs for other things, so I don't think there's much point in continuing this as it clarifies your intentions for the nixpkgs design. I have been using nix, and more recently nixpkgs, in place of stack, but if you are not then we simply have different goals and the issues I raise are not relevant.

Anthony