Extension Stopped working due to HLS ghc deprecation

[mduerig]

haskell-language-server 1.5.0 for GHC 8.10.4 is not available on Linux. See the list of supported versions

Was working fine until recently. No changes on my end.

[jneira]

Sorry to read that. I am afraid that haskell-language-server, the lsp server behind the extension, has deprecated that ghc version.
You can read more about ghc support deprecation here:
https://haskell-language-server.readthedocs.io/en/latest/supported-versions.html

The suggestion is upgrade your ghc to 8.10.7. It should not be very difficult as your projects compiled with 8.10.4 should work in most cases with 8.10.7.

Another alternative is continue using haskell-language-server-1.4.0 setting the option haskell.updateBehavior to never-check. It should continue using the already downloaded hls-1.4.0

[mduerig]

Thanks @jneira . The deprecation plan seems quite aggressive though. I was on LTS Haskell 18.6 (ghc-8.10.4) from August 20-th this year. Despite LTS, this is already deprecated?

Is there a way to tie the HLS used by vscode to a fixed version on a per project basis?

From a usability POV I find the current behaviour quite problematic as it keeps breaking things that used to work only a few weeks earlier without a clear indication on how to fix this.

[jneira]

The deprecation plan seems quite aggressive though. I was on LTS Haskell 18.6 (ghc-8.10.4) from August 20-th this year. Despite LTS, this is already deprecated?

Well, there are LTS's for ghc as olders a ghc-7.8.3. So the existence per se of a LTS cant be a criteria to keep compatibility.
As i mentioned bump up ghc minor versions when there is a newer LTS supporting it (like https://www.stackage.org/lts-18.17 for 8.10.7) usually are not problematic. Please let us know if you have problems in that process to see if we can help in any way.

Otoh support minor versions have a cost in maintainability and ci resources. Time and resources which can be used to fix bugs and add new features. HLS is a open source project driven by voluntary work and donations so our resources are very limited.

You can read more about the rationale here:
https://haskell-language-server.readthedocs.io/en/latest/supported-versions.html#why-deprecate-older-versions-of-ghc

As mentioned in the docs linked above, you have two options to continue using the extension and hls for your actual ghc version:

• Keep using hls-1.4.0
• Build hls from source for that ghc version. there are several methods to do it: https://haskell-language-server.readthedocs.io/en/latest/installation.html#installation-from-source and https://haskell-language-server.readthedocs.io/en/latest/installation.html#ghcup

[jneira]

without a clear indication on how to fix this.

Good point, i think there is quite info in the hls documentation and the extension links directly to such documentation at top.
In the supported ghc section we link to the mentioned https://haskell-language-server.readthedocs.io/en/latest/supported-versions.html

But i think we should add a specific paragraph about what to do when your actual ghc is deprecated (linking to hls docs as well)

[konn]

FWIW, you can bump up the minor version of GHC without changing the LTS minor version by explicitly specifying compiler in stack.yaml:

resolver: lts-18.6
compiler: ghc-8.10.7

If the major version is different than LTS's standard version, it can be problem - but if the major version matches, basically same LTS would work for newer versions of GHC with the same major version (i.e. 8.10.* in this case).

[michaelpj]

I think we discussed in the past the possibility of the extension downloading old versions of HLS if you're on an old version of GHC, but that might be quite complicated. But in lieu of that, I think it would be fine to have a short paragraph pointing people to the doc and telling them they need to install the old version themselves if they want it.

[lukel97]

Thanks @jneira . The deprecation plan seems quite aggressive though. I was on LTS Haskell 18.6 (ghc-8.10.4) from August 20-th this year. Despite LTS, this is already deprecated?

Just a heads up (I agree it's a bit confusing unfortunately) but the long-term-support referred to by LTS Haskell 18.6 refers to the stackage snapshots, not the version of GHC itself. GHC doesn't make any LTS guarantees

[jneira]

I think we discussed in the past the possibility of the extension downloading old versions of HLS if you're on an old version of GHC, but that might be quite complicated. But in lieu of that, I think it would be fine to have a short paragraph pointing people to the doc and telling them they need to install the old version themselves if they want it.

Agree, but in theory, if you already was using a hls version via the extension it will be available if you did not remove it manually (the extension does not remove old versions) so putting haskell.updateBehavior to never-check should make it work again afaiu (i've not tested it)

@mduerig could you confirm if doing that fix the issue for you?

[mduerig]

@jneira, setting haskell.updateBehavior to never-check doesn't work for me. I still get the same error message "haskell-language-server 1.5.0 for GHC 8.10.4 is not available...". It looks like this is cached somewhere as this even happens when disconnected from Wifi.

[mduerig]

What does work though is setting Server Executable Path to ${HOME}/.config/Code/User/globalStorage/haskell.haskell/haskell-language-server-1.4.0-linux-8.10.4.

Putting this config into my workspace settings should allow me to tie the HLS version to the GHC version of individual projects. However, I'm a bit concerned about the deprecation note that goes along with that setting: "Deprecated scope: This option will be set to machine scope in a future release, so it can be changed only globally, not per workspace." Why would you do that? At least for me it is a common use case to jump between many small projects, each on a different GHC version and I wouldn't want to reconfigure my tooling each time I switch.