Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

amazonka base revisions prevent building in Stackage Nightly! #988

Closed
juhp opened this issue May 13, 2024 · 4 comments
Closed

amazonka base revisions prevent building in Stackage Nightly! #988

juhp opened this issue May 13, 2024 · 4 comments

Comments

@juhp
Copy link

juhp commented May 13, 2024

It is seems amazonka packages got revised to base < 4.19 on Hackage:
see for example https://hackage.haskell.org/package/amazonka-2.0/revisions/

Given that is was building is this really correct?
Maybe the intention was base < 4.20??

cc @JackKelly-Bellroy ?

@endgame
Copy link
Collaborator

endgame commented May 13, 2024

Yep, that's intentional According to Base Package (HaskellWiki), base-4.19 corresponds to GHC 9.8, and if the linked issue is correct, only ~20 of the ~330 amazonka-* packages were compiling with GHC 9.8. Missing from that list is amazonka itself (necessary for user programs to make AWS calls in an ergonomic way) as well as bindings for many core AWS services like S3, Lambda, EC2, and IAM. Any service which has a record that shares a field name with any other record in the same service will fail to compile because GHC 9.8 changed (for the better) where you need to place {-# LANGUAGE DuplicateRecordFields #-}. See #969 for the original Amazonka bug, #972 for the PR to fix the generator, and #973 for the regeneration of service bindings.

The bounds revisions therefore seem largely correct. If you think that re-revising bounds will improve things for your workloads (should I be raising the base upper bound on just the packages listed in your linked Stackage issue?), then I can raise the upper bound for the 2.0 releases on Hackage.

@juhp
Copy link
Author

juhp commented May 13, 2024

Okay thanks for responding so fast: apologies looks like I probably "pulled the trigger too fast" - you are right it's not that many packages...

I just wasn't sure what was going on, so the detailed explanation is most helpful. Again sorry for pointing a finger at you 😔

@juhp
Copy link
Author

juhp commented May 13, 2024

I removed the accusatory sentence from the description, sorry again - I should have checked more carefully on the status: though I couldn't see any obvious recent ticket here immediately.

I know time is limited for all of us: a heads-up or stackage removal could have helped too - anyway thanks again for the quick response and correcting me.

@endgame
Copy link
Collaborator

endgame commented May 13, 2024

I appreciate that mate, thank you. I've edited out my prickly response, too, so we can call it even.

@endgame endgame closed this as completed May 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants