Closed jneira closed 2 years ago
One other problem is when a user use stack; Depending on projects snapshot, it will use different GHC versions, so it's not possible to install HLS before starting a specific project
One other problem is when a user use stack; Depending on projects snapshot, it will use different GHC versions, so it's not possible to install HLS before starting a specific project
Yeah it will download when starting the stack or cabal project but it will able to query the matrix of ghc supported versions * hls versions and download the appropiate one
Ah by "not possible ... before starting a specific project", I mean even when a machine already has a HLS binary, it still needs to check the GHC used in the project and downloads older/newer HLS
Yes, this is awkward. Note that this isn't just a concern for stack. There are also nix builds where the GHC version is determined by the build config rather than using GHC from the path. Even worse, if the project uses multi-cradle, then there may be different parts of the project that build with different GHC versions. The GHC version used by HLS will depend on the choice made by haskell-language-server-wrapper
, and I'm not sure of the logic there.
Looks like we can ask haskell-language-server-wrapper --project-ghc-version
which GHC it will infer. That would still require downloading a HLS (presumably the most recent one) in order to run the wrapper and ask the question. Hopefully it succeeds even without a supported GHC installed. Of course, this might still be wrong for complex builds like mentioned above, since GHC version inference isn't perfect... but only when HLS would have been broken anyway.
I guess I would advocate something like:
This will fail if HLS gets smarter in the latest version about inferring the right GHC version, but it's probably better than just using the latest version.
Can we ask haskell-language-server-wrapper which GHC is will infer
yeah haskell-language-server-wrapper --project-ghc-version
Determine which HLS version the wrapper script would run, preferably by downloading the latest HLS and asking it if possible.
Not sure if i am understanding it fully but the extension already does something similar:
haskell-language-server-wrapper --project-ghc-version
in the project root dirWe "simply" have to change it to download from older releases if the ghc is not supported by the last one
Okay, great! Sounds like a good plan, then, and stack and nix builds will not be broken (unless they already were)
I just wanted to note that I this issue is important to me. For simplicity, I'm using stack for my class this semester and have configured all course projects and autograders to use the same lts. In August, I selected the most recent lts that worked with all of the tools that I wanted to use (hlint, ormolu, vscode) on all platforms. However, in November, haskell-language-server dropped support for GHC-8.10.4. I'd really like to be able to use vscode with older versions of GHC when necessary, without resorting to the workarounds in #504.
Maybe Haskell Foundation can help? I'll also add an issue to https://github.com/haskellfoundation/tech-proposals so that they know about it.
Created PR #506 to start addressing this.