Looking for hls old versions compatibles with the requested ghc version

[jneira]

• hls is deprecating support for ghc versions (see https://github.com/haskell/haskell-language-server/issues/2168)
• but we could continue supporting it with older hls version
• to do it automatically when downloading the executable we should look for an appropiate hls version in older releases
• it could be done on the fly but if we teach the extension the matrix of hls/ghc versions, we could go directly for the desired one and we could improve error messages when a ne ghc version is not supported at all (see #453)
• the extension should show an alert message (maybe a confirmation message?) when downloading and old version (as it will not have the same feature set and could suffer some bugs)

[Ailrun]

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

[jneira]

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

[Ailrun]

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

[cdsmith]

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:

1. Determine which HLS version the wrapper script would run by downloading the latest HLS and asking it if possible.
2. Look for that GHC version.

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.

[jneira]

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:

1. Downloads haskell-wrapper-server
2. Execute haskell-language-server-wrapper --project-ghc-version in the project root dir
3. Download the hls executable suited for that ghc version from the last hls github release

We "simply" have to change it to download from older releases if the ghc is not supported by the last one

[cdsmith]

Okay, great! Sounds like a good plan, then, and stack and nix builds will not be broken (unless they already were)

[sweirich]

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.

[sweirich]

Maybe Haskell Foundation can help? I'll also add an issue to https://github.com/haskellfoundation/tech-proposals so that they know about it.

[mduerig]

Created PR #506 to start addressing this.