Please relax bounds: older versions of Cabal don't build with newer dependencies

[tomjaguarpaw]

• This fails cabal-3.10.1.0 repl -z -b 'Cabal==3.6.3.0' -w ghc-9.8
• This works cabal-3.10.1.0 repl -z -b 'Cabal==3.6.3.0' -w ghc-9.8 -b unix==2.8.5.0 -b text==2.1 -b bytestring==0.12.0.2 -b deepseq==1.5.0.0 --allow-newer=unix --allow-newer=text --allow-newer=bytestring --allow-newer=deepseq

Conclusion: Cabal-3.6.3.0 should probably have its bounds loosened to incorporate those versions (and probably others in the 3.6 series too).

• This fails: cabal-3.10.1.0 repl -z -b 'Cabal==3.8.1.0' -w ghc-9.8
• This works: cabal-3.10.1.0 repl -z -b 'Cabal==3.8.1.0' -w ghc-9.8 -b text==2.1 -b bytestring==0.12.0.2 -b deepseq==1.5.0.0 --allow-newer=text --allow-newer=bytestring --allow-newer=deepseq

Conclusion: Cabal-3.8.1.0 should probably have its bounds loosened to incorporate those versions (and probably others in the 3.8 series too).

I appreciate that those versions are not the latest, but I'm sure people do use them even if they "should" upgrade. The too-strict bounds do incur problems in practice, such as https://discourse.haskell.org/t/why-is-latest-version-of-cabal-sometimes-required-to-build/8017.

[Mikolaj]

See also #9590.

I wonder how to go about it. In principle, we require Hackage revisions to be reflected in the repo. But CI on these branches is dead, so we'd introduce changes we can't properly test. Let's discuss in the cabal devs meeting in two days (@tomjaguarpaw, you are kindly invited).

[tomjaguarpaw]

Ah, OK, thanks. Maybe that means using cabal-3.10 really is the correct solution (and to be clear, it is indeed a good enough workaround).

[ulysses4ever]

By all means, please consider switching to 3.10: it's in a much better shape upstream in a sense.

[tomjaguarpaw]

I personally have switched to 3.10, but unsuspecting others will still be using 3.6 or 3.8 just because those are what they have installed. Then they'll get error messages like the below, which are absolutely baffling. I wouldn't have been able to diagnose the error on my own, for example. I'm glad some folks at Haskell Discourse were able to help me:

https://discourse.haskell.org/t/why-is-latest-version-of-cabal-sometimes-required-to-build/8017

[Mikolaj]

While we are discussing whether to reflect bound changes on our old (and broken) branches, let's make the necessary Hackage revisions without waiting. A PR with the bumps for each branch would be helpful, just to test, at least locally, that it builds, even though the full CI run is going to fail. Even if the PR does end up merged, it's still a helpful documentation of the process (please note down in the PR whether building succeeded in CI and on what architectures and GHC versions). IIRC one can comment on Hackage what PR corresponds to what bounds change [edit: I made that up; this is not yet a feature of Hackage, but I think it would be worthwhile].

@andreabedini: do trustees try to keep very old cabal versions (<= 3.4 currently) working? I wonder if PRs even make sense for these. Do you build the revised packages in such cases or just guess the bound changes make things better than they were?

[Mikolaj]

OTOH, relaxing the bound on cabal 3.6 to compile/work with GHC 9.8 may be actively misleading, because we know this pair doesn't work on Windows and never will. Aren't bounds supposed to express just this kind of information [edit: they aren't]? This underlies the need to have CI pass at least the build step for all architectures, before a revision is attempted. I wonder, perhaps 3.6+9.8 actually passes the build step, because the insurmountable breakage only appears when using the cabal exe, and probably not for the most mundane uses? What do you all think?

Edit: but then, cabal-install build-depends bounds only express what GHC/package versions cabal can be built with, not what GHC version cabal can work with. The warnings "cabal doesn't know this GHC" serves the latter purpose. Did the warning show up correctly in the case you describe on discourse, @tomjaguarpaw? Did users learn to ignore the warning?

[ulysses4ever]

Maybe there's a cheap way to improve just the error message that @tomjaguarpaw saw? After all, custom setup issue is a pretty specific scenario.

[tomjaguarpaw]

Maybe there's a cheap way to improve just the error message that @tomjaguarpaw saw?

Any improvement will have to be in new code. If it's in new code in the 3.6 or 3.8 series then it runs into the problems the Mikolaj describes about being unable to test it. If it's in new code in the 3.10 series then that's great for the future, but doesn't help people currently using 3.6 or 3.8.

I'm getting the impression that my suggestion has several knock-on impacts, and I'm not in a position to assess those impacts. I think the advice to "just use the latest version of cabal-install" is fine in this instance. In general it would be great if there were a longer support window, but I don't want to advocate for that in this case. I will understand if you close this as "won't fix"!