Allow hashable-1.5

[Bodigrim]

Currently restricted by

cabal/cabal-install/cabal-install.cabal

Line 234 in 1837262

hashable >= 1.0 && < 1.5,

[geekosaur]

We have a bigger restriction, it turns out: CI uses ghc 9.4.8, but hashable-1.5 requires at least ghc 9.6.1.

[ulysses4ever]

We have a bigger restriction, it turns out: CI uses ghc 9.4.8, but hashable-1.5 requires at least ghc 9.6.1.

@geekosaur I don't see why it's a restriction necessarily. Normal CI doesn't have to exercise all possible versions of dependencies. We "just" need to ensure that we can build with hashable-1.5 in cases where the plan allows. It may be the case that there's no such plan, and then you have to figure out why. cabal-plan can help with that. Usually, it's some of our dependencies that don't allow 1.5. In that case, you need to open issues against those dependencies...

[geekosaur]

We have a bigger restriction, it turns out: CI uses ghc 9.4.8, but hashable-1.5 requires at least ghc 9.6.1.

@geekosaur I don't see why it's a restriction necessarily. Normal CI doesn't have to exercise all possible versions of dependencies. We "just" need to ensure that we can build with hashable-1.5 in cases where the plan allows. It may be the case that there's no such plan, and then you have to figure out why. cabal-plan can help with that. Usually, it's some of our dependencies that don't allow 1.5. In that case, you need to open issues against those dependencies...

It's not our dependencies. hashable-1.5 requires a newer base than is shipped with ghc 9.4.x, but our CI uses 9.4.8. If you want to force hashable-1.5 you must also bump the ghc version to 9.6.

[ulysses4ever]

I don't understand: our CI exercises a multitude of GHC starting from something like 8.4. Do you mean GHC_FOR_RELEASE? But it has no special role in checking that loosening the bound works. If at least one GHC can build and pass the tests, that should be good enough for this particular purpose (loosening the bound).

[ulysses4ever]

This run shows that at least one of our dependencies (tree-diff) doesn't allow hashable-1.5. It theory, an interested party should open an issue on tree-diff's tracker, and re-run the pipeline with allow-newer: tree-diff:hashable to either discover more such dependencies or proceed with Validate proper...

[geekosaur]

This is a different result than I got originally, when the static Alpine job failed because it was using ghc 9.4.8.

[ulysses4ever]

oh, so you are referring to the Static Apline job in particular -- sorry, I got totally confused! Yeah, in that case maybe the easiest way is to verify locally. A possible workaround would be to manually re-run just one job with a new enough GHC, I think.

The current failure I see is due to (afaiu) how you spell the version in the arguments to the manual run: 1.5 instead of 1.5.0.0 (it is unfortunate that you can't omit the zeroes...).

[geekosaur]

BTW what failure we see is somewhat random because whichever job fails first kills the others, so it's a toss up whether we see the tree-diff error or the hashable one, I think

[ulysses4ever]

@geekosaur not really: the Static Alpine job is an independent job, not a part of the validate step matrix. So, I think it should be pretty consistent.