3.14 pre-flight checks: bump dependencies #10244
Conversation
| @@ -19,7 +19,7 @@ library | |||
| , QuickCheck | |||
| , rere >=0.1 && <0.3 | |||
| , tasty <1.6 | |||
| , tasty-quickcheck <0.11 | |||
| , tasty-quickcheck <0.12 | |||
There was a problem hiding this comment.
The API changed, according to CI. Do we want to bump and conditionalize, or leave it at the old version?
There was a problem hiding this comment.
True... In particular, it looks like it's only one file?
tests/UnitTests/Distribution/Solver/Modular/QuickCheck/Utils.hs:35:24: error: [GHC-83865]
Error: • Couldn't match expected type: (Test.QuickCheck.Random.QCGen, Int)
with actual type: Maybe a0
• In the pattern: Nothing
In the pattern: QuickCheckReplay Nothing
In a case alternative:
QuickCheckReplay Nothing -> getStdRandom random
|
35 | QuickCheckReplay Nothing -> getStdRandom random
| ^^^^^^^
(and two more errors like that). In tasty-quickcheck-0.11 this constructor has changed. There's another constructor that appeared in 0.11, QuickCheckReplayLegacy that is close to the one we use (sans Maybe).
How could we conditionalize btw? Leaving <0.11 would be fine, perhaps, but then every time we do cabal outdated (as per the wiki) it will make some noise -- I'm not a fan of that. I'd rather we had clean cabal outdated. In particular, if it's a matter of adding CPP in one tiny file in the test suite, I'd be fine with that.
There was a problem hiding this comment.
Yeh, by "conditionalize" I meant CPP on MIN_VERSION_tasty_quickcheck or whatever it is.
There was a problem hiding this comment.
@Kleidukos @Mikolaj opinions? Options with supporting tasty-quickcheck starting from 0.11 are:
- add CPP
- don't support it, stick to <0.11
- support versions starting from 0.11. It looks like it's only a test dependency (but in the cabal-install package), so it's probably not too bad regarding the support window.
There was a problem hiding this comment.
It looks like UnkindPartition/tasty#425 may provide the same functionality as that utils file, so we may be able to upgrade tasty and delete the whole file eventually.
There was a problem hiding this comment.
Yes obviously my pick is conditioned by "Does the CI pass" ;-)
There was a problem hiding this comment.
Yes, I think that we should start with (1) or (3), depending on what is required to satisfy the build, and then move towards (3), since tasty-quickcheck is only a test dependency.
There was a problem hiding this comment.
Hey all. I put ^>=0.11 for tasty-quickcheck, and CI seems to be fine with it. Check it out.
There was a problem hiding this comment.
Great! I verified that the QuickCheck seeds are being displayed correctly with the new API: https://github.com/haskell/cabal/actions/runs/10241795977/job/28330597202#step:19:17
There was a problem hiding this comment.
Oh, that's great, because I wasn't sure.
ulysses4ever
force-pushed
the
outdated-3.14
branch
from
385f573
to
5c1f374
Compare
ulysses4ever
force-pushed
the
outdated-3.14
branch
from
5c1f374
to
7788026
Compare
ulysses4ever
added
squash+merge me
mergify
bot
added
the
merge delay passed
* allow hashable-1.5 * allow tasty-quickcheck 0.11, and in case of cabal-install:test move to ^>=0.11 --------- Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
Template B: This PR does not modify behaviour or interface
E.g. the PR only touches documentation or tests, does refactorings, etc.
Include the following checklist in your PR:
Is this a PR that fixes CI? If so, it will need to be backported to older cabal release branches (ask maintainers for directions).