Revision changing semigroupoids 5.0.1 dependencies breaks old Stackage releases

[blitzcode]

Earlier this year there was a revision to the 2016 semigroupoids 5.0.1 release:

https://hackage.haskell.org/package/semigroupoids-5.0.1/revisions/

The lower bound of the tagged dependency was changed from >=0.7.3 to >=0.8.5.

This breaks all older Stackage releases that include semigroupoids 5.0.1 but obviously not tagged 0.8.5.

Why would you change the dependencies of a years old release, breaking all stackage builds including it in the process?

[RyanGlScott]

@phadej, thoughts?

[rspeer]

I just encountered this as well, though I had no idea what the source of the problem was. Code that I wrote about a year and a half ago, with its dependencies reasonably sorted out via Stack, didn't compile anymore because of semigroupoids, a library that I didn't know I depended on.

I took this as a sign that I should upgrade from Stack lts-5.11 to lts-11.6, but it left me disappointed in what "long term support" means in the Haskell ecosystem.

[phadej]

I think it's already discussed in depth in commercialhaskell/stackage#3185 Explicit revision and one can recover old build plan

…

Sent from my iPhone

On 23 Apr 2018, at 22.05, Rob Speer ***@***.***> wrote: I just encountered this as well, though I had no idea what the source of the problem was. Code that I wrote about a year and a half ago, with its dependencies reasonably sorted out via Stack, didn't compile anymore because of semigroupoids, a library that I didn't know I depended on. I took this as a sign that I should upgrade from Stack lts-5.11 to lts-11.6, but it left me disappointed in what "long term support" means in the Haskell ecosystem. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[blitzcode]

Ok, trying to parse through this big web of bug reports and reddit discussion I can see that the Stack people have prevented this from happening in the future, but I still don't understand why one would make such a drastic change to a two years old release and break countless builds in the process or what the canonical correct fix is to get older snapshots working again.

[ekmett]

Revisions are mostly used as a tool to ensure that if you go to grab an old version of ghc and try to build something you don't have to magically guess the bounds on all of your dependencies to try to get back into the state the world existed in at the time. Developers aren't psychic, so occasionally we wind up with mismatched bounds, or somebody screws up their respect of the PVP, or somebody adds a combinator that causes a name clash that affects somebody else who was following the PVP in general, but used unqualified imports.

They let us give somewhat more liberal bounds and fix things after the fact when they do turn out to be a problem.

Stackage snapshots do much the same thing, ensuring you have a bunch of packages that to the best of our knowledge work together, but until recently they were missing the functionality to take only the revisions from the time the snapshot was created. This was a limitation of the stack model and how it interacted with the rest of the ecosystem that has since been fixed.

From LTS 6 (two years ago) forward they now make sure to take a 'truly immutable' view of cabal as it existed at the time of the snapshot for the elements of the snapshot.

You with 5.11 just happened to fall right below the cut-off for where this is fixed automatically.

Mind you, "LTS" in haskell isn't on the scale of Debian and the like. When the LTS feature was proposed the idea was 3-4 month windows, which seems admittedly absurdly small, but it was what Snoyman could wrangle folks to agree to! Two years exceeds that by a fair bit, so we're rather exceeding our ridiculously modest aims. Set the bar low enough and your major concern is tripping over it, I guess.

History lesson aside, the workaround here is to add allow-newer: true to your stack.yaml. Despite the name of the flag, it'll ignore both upper and lower bounds and just accept the forced plan. That should get you by until you can upgrade to a more current LTS release.

tl;dr Add allow-newer: true to stack.yaml for now.

[ekmett]

Closing this as there really is nothing we can or should do actively on this point. The issue has been fixed for a couple of years in stack, and plans that would involve building a counter-revision that retroactively fixed old LTS versions would cause additional churn problems.