search

haskell / cabal

Official upstream development repository for Cabal and cabal-install
https://haskell.org/cabal
Other
1.61k stars 691 forks source link

Allow hashable-1.5 #10177

Open Bodigrim opened 3 months ago

Bodigrim commented 3 months ago

Currently restricted by https://github.com/haskell/cabal/blob/1837262b1dd533eaf0b4ddbc6c373b9c39351e5d/cabal-install/cabal-install.cabal#L234

geekosaur commented 3 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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

ulysses4ever commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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