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

Missing upper bounds on ghc on hackage #117

Open
andreasabel opened this issue Dec 24, 2021 · 4 comments
Open

Missing upper bounds on ghc on hackage #117

andreasabel opened this issue Dec 24, 2021 · 4 comments

Comments

@andreasabel
Copy link

Leaving through the releases of apply-refact on hackage, I see no upper bounds on ghc starting with release 0.7.0.0.
This may not reflect buildability correctly, see e.g. #114.
What would be the correct upper bound for the released versions?

@zliu41
Copy link
Collaborator

zliu41 commented Jan 2, 2022

@andreasabel Thanks for catching this. I've updated the upper bounds of base for the latest several versions on Hackage. Since ghc versions map 1:1 to base versions, will remove bounds on ghc in future releases.

@andreasabel
Copy link
Author

@zliu41 wrote:

Since ghc versions map 1:1 to base versions, will remove bounds on ghc in future releases.

Are you sure about this? Aren't there two GHCs to consider?

  • The GHC you are compiling apply-refact with (here, a bound on base can be used to restrict compilability---although I do not see why one would restrict this way).
  • The GHC library you are using (to parse, print, manipulate Haskell code). This is the ghc package, I suppose.

@zliu41
Copy link
Collaborator

zliu41 commented Jan 5, 2022

My understanding is that you can't depend on a different version of the GHC library than the GHC compiler version you are using. That is the whole reason why ghc-lib exists.

So there's no need to have bounds on both base and ghc. While I don't have a preference on which one to put the bounds on, almost all Hackage packages have bounds on base so I chose base.

@andreasabel
Copy link
Author

I think because build failures (e.g., https://github.com/ndmitchell/hlint/runs/4691040973?check_suite_focus=true#step:8:286) happen due to changes in the ghc module rather than changes in base, it would make more sense to put the relevant bounds on ghc.

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