-
Notifications
You must be signed in to change notification settings - Fork 25
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
Make it build with ghc 9.12 #1406
base: main
Are you sure you want to change the base?
Conversation
d7e36b3
to
226d273
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR looks good, but I wonder if we want to merge it with those allow-newer
.
Also I'd rather wait until the 10.3 branch is rebased onto latest main, before merging this one
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All the changes look mild (🙌) except that ref=for-stackackage
in the haskell.nix
declaration.
@@ -16,7 +16,7 @@ | |||
inputs.hackage.follows = "hackageNix"; | |||
}; | |||
hackageNix = { | |||
url = "github:input-output-hk/hackage.nix"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not familiar with the broader consequences of this change. The haskell.nix
repo says:
The for-stackage branch also contains all cabal expressions from hackage.org as nix expressions.
This branch is used when working with stack projects in haskell.nix.
Could you summarize the potential reasons to not use it? And what is requiring its use here? The Consensus build process (eg CI) generally doesn't involve stack.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is some Nix magic foo. @angerman might be able to explain.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@angerman responded in Slack and can be posted here:
Newer haskell.nix doesn't need hackage.nix to a large degree anymore, as .cabal -> .nix expressions are derived in the fly. As such hackage.nix (in it's old form doesn't exist anymore); we still keep it around to support stack and stackage. We are stuck with an old haskell.nix version until we can upgrade past ghc 8.10. Hence this rather annoying mismatch between hacakge.nix and haskell.nix, leading to older haskell.nix versions now needing to use the for-stackage branch (which is still periodically updated with new .nix expressions for the .cabal files in the hackage index).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe a comment in the nix
file, such as # workaround haskell.nix and hackage.nix being out of sync until we drop support for GHC 8.10
or some such
The
That is fine. |
No longer needed. GHC has been deriving this typeclass for some time and ghc-9.12 now warns about it being redundant.
stackackage 🤣 |
Description
Make it build with ghc 9.12
Also note that: