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

Remove handling of ghc-x.y hls executables #1728

Closed
jneira opened this issue Apr 14, 2021 · 4 comments · Fixed by #1805
Closed

Remove handling of ghc-x.y hls executables #1728

jneira opened this issue Apr 14, 2021 · 4 comments · Fixed by #1805
Labels

Comments

@jneira
Copy link
Member

jneira commented Apr 14, 2021

(from a question in irc by arrowsvc)

  • In several places the code is assuming a hls version compiled with ghc-x.y should (or could) work with all ghc-x.y.z runtime versions
    • hls-wrapper tries to use hls-x.y.z, hls-x.y and hls inthat order
    • the install script copies an hls version as hls-x.y
    • that assumption was inherited from hie but i think it worked in hls at some point (???)
  • But you cant use that version with ghcide: ghcide compiled against GHC x.y.z but currently using x.y.w ...

So we should either make it work (again?) or remove its existence, cause it causes confusion
/cc @pepeiborra

@pepeiborra
Copy link
Collaborator

pepeiborra commented Apr 17, 2021

I don't think that we can guarantee compatibility across ghc versions, so my vote is for removing the handling too

@jneira
Copy link
Member Author

jneira commented Apr 22, 2021

That is unfortunate, i was planning cover all supported ghc versions with only 3 executables when setting up the chocolatey package for hls, but download all the minor verisons is a no go 😢

@ndmitchell
Copy link
Collaborator

@jneira - how would that work? Don't the minor variations between different GHC versions cause everything to go incompatible? Or, asked another way, what are the guarantees required to use a GHC 8.6.4 binary with 8.6.5, and could we get GHC HQ to commit to them?

@jneira
Copy link
Member Author

jneira commented Apr 26, 2021

It worked for haskell-ide-engine (hls inherited the code handling ghc-x.y from it), and i thought it did it for hls at some point, but surely i am wrong and never did it.
So i guess hie relied in the fact that if ghc patch version supposes no changes in the external api, nor error messages format or other info extracted you can handle an older ghc at runtime with a a version compiled against a newer one.

So the answer to

what are the guarantees required to use a GHC 8.6.4 binary with 8.6.5, and could we get GHC HQ to commit to them?

would be "no one, for the general case", so the safer option is require the exact version.

I am implementing another strategy for the choco package, assuming the fix to this issue will be to remove the handling of minor versions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants