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.

[sweirich]

I'm having the same issue and tried setting Server Executable Path as above.

However, this doesn't work for me--
serverExecutablePath is set to /Users/sweirich/Library/Application\ Support/Code/User/globalStorage/haskell.haskell/haskell-language-server-1.4.0-darwin-8.10.4 but it doesn't exist and it is not on the PATH

This file does exist on my machine:
sweirich@SEASNet-50-03 src % ls /Users/sweirich/Library/Application\ Support/Code/User/globalStorage/haskell.haskell/haskell-language-server-1.4.0-darwin-8.10.4 /Users/sweirich/Library/Application Support/Code/User/globalStorage/haskell.haskell/haskell-language-server-1.4.0-darwin-8.10.4

I'm teaching a class have set up the configuration to be exactly 8.10.4 for all of my materials this semester. How can I tell vscode-haskell to use the older version of haskell-language-server?

[sweirich]

Also, setting setting haskell.updateBehavior to never-check doesn't work for me. It was already set to update, so it did. I need the ability to choose the language-language-server version.

[jneira]

@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.

thanks for checking, will revise the code, afaiu it should not even try to know if there is a new version and use the executables already available

It looks like this is cached somewhere as this even happens when disconnected from Wifi.

is there any file with the 1.5.0 extension in ${HOME}/.config/Code/User/globalStorage/haskell.haskell? it is the unique cache location i can think of...

The issue about handling old versions of hls is #454, will prioritize it but pull request will be very welcomed

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?

Due to security reasons as you can download a directory which could run a harmful executable automatically when opening it in vscode.

But the option will not change its scope until we got another way to not break people workflows, see #387

I think another workaround would be set export PATH=${HOME}/.config/Code/User/globalStorage/haskell.haskell:$PATH and all workspaces will work as before without setting the server executable path for any of them.

[jneira]

is there any file with the 1.5.0 extension in ${HOME}/.config/Code/User/globalStorage/haskell.haskell? it is the unique cache location i can think of...

🤦 there is one: ${HOME}/.config/Code/User/globalStorage/haskell.haskell/latestApprovedRelease.cache.json

So i think replacing it with the appropiate one for 1.4.0 and keep haskell.updateBehavior to never-check could workaround the issue as well.

Fortunately i still had it in my machine and i even had no to regenerate with github api calls 😸

latestApprovedRelease.cache.json.zip

[mduerig]

is there any file with the 1.5.0 extension in ${HOME}/.config/Code/User/globalStorage/haskell.haskell? it is the unique cache location i can think of...

Yes, there is haskell-language-server-1.5.0-linux-8.10.7. Probably placed there when opening another project using a newer GHC version. There's also latestApprovedRelease.cache.json containing meta data about the the files at that location.

[jneira]

One of the major drawbacks of the workarounds i ve proposed is you can not use newer versions of hls for other projects using supported ghcs 😞

[sweirich]

Thanks for the cached json file --- that worked for me. However, I'm still confused why changing the Server Executable Path doesn't work.

[jneira]

Thanks for the cached json file --- that worked for me. However, I'm still confused why changing the Server Executable Path doesn't work.

What value did you set in the path? what error did you got?

[sweirich]

In #504 (comment), the first part is the error message. The value that I used was /Users/sweirich/Library/Application\ Support/Code/User/globalStorage/haskell.haskell/haskell-language-server-1.4.0-darwin-8.10.4

[jneira]

Oh sorry i missed your comment. The code use a call to which /Users/sweirich/Library/Application\ Support/Code/User/globalStorage/haskell.haskell/haskell-language-server-1.4.0-darwin-8.10.4: does it work in a shell?

vscode-haskell/src/utils.ts

Lines 276 to 281 in 627b1da

	export function executableExists(exe: string): boolean {
	const isWindows = process.platform === 'win32';
	const cmd: string = isWindows ? 'where' : 'which';
	const out = child_process.spawnSync(cmd, [exe]);
	return out.status === 0 || (isWindows && fileExists(exe));
	}

[sweirich]

Yes, the which /Users/sweirich/Library/Application\ Support/Code/User/globalStorage/haskell.haskell/haskell-language-server-1.4.0-darwin-8.10.4 command succeeds.

[jneira]

Uhmm try /Users/sweirich/Library/Application\\ Support/Code/User/globalStorage/haskell.haskell/haskell-language-server-1.4.0-darwin-8.10.4 (with double \)

[sweirich]

Sadly, that doesn't work either. I also tried it (earlier) with "s.

serverExecutablePath is set to /Users/sweirich/Library/Application\\ Support/Code/User/globalStorage/haskell.haskell/haskell-language-server-1.4.0-darwin-8.10.4 but it doesn't exist and it is not on the PATH

[jneira]

Sorry running out of ideas and i dont have a mac to check my guesses but i would try to move the file to some simple and short place. But maybe is time to open another issue 🤔

[lukel97]

@sweirich Is it possible that the space doesn't need escaped? vscode-haskell spawns which directly without a shell, so I'd imagine passing in space-y paths without the backslash should be fine

[mduerig]

@sweirich I just tried @bubba 's suggestion on a Mac and it worked: with .../Application\ Support/... I get the same error about the executable not being found. However, using .../Application Support/... (without the escaping of the whitespace) all is good.

[sweirich]

Thanks. Removing the \ also worked for me.