[WSL] VS Code will download binaries even if HLS is on $PATH opening several projects/files

[mixphix]

Your environment

Output of haskell-language-server --probe-tools or haskell-language-server-wrapper --probe-tools:

haskell-language-server version: 1.4.0.0 (GHC: 8.10.7) (PATH: /home/melanie/.cabal/store/ghc-8.10.7/haskell-language-server-1.4.0.0-e-haskell-language-server-a5c013b61c50ee23e57b3b466678b998047567c6c45ad0b234b9c91d1b4bd48c/bin/haskell-language-server)
Tool versions found on the $PATH
cabal:          3.6.2.0
stack:          2.7.3
ghc:            9.0.1

Which OS do you use: Ubuntu via WSL

Which lsp-client do you use: VS Code

Describe your project (alternative: link to the project): any project (or $HOME)

Contents of hie.yaml:

cradle:
  cabal:

Steps to reproduce

Each time I run rm -rf $HOME/.vscode-server/data/User/globalStorage/haskell.haskell then reload VS Code on WSL and open a .hs file, the extension warns me that it is redownloading the binaries for HLS. This is despite the integrated terminal reporting

$ which haskell-language-server
$HOME/.cabal/bin/haskell-language-server

that I installed with GHCup. Once the binaries finish downloading, I receive the error mentioned in haskell/haskell-language-server#236: Project requires GHC but it isn't installed, despite the integrated terminal reporting

$ which ghc
$HOME/.ghcup/bin/ghc

Expected behaviour

VS Code should not download the prebuilt binaries, but should instead use the version of HLS found on the $PATH.

Actual behaviour

If the binaries in the extension folder do not exist, VS Code will automatically redownload them, failing to recognize the existing HLS installation.

Include debug information

Execute in the root of your project the command haskell-language-server --debug . and paste the logs here:

Debug output: N/A

Paste the logs from the lsp-client, e.g. for VS Code

LSP logs: Cradle requires cabal but couldn't find it

[client][ERROR] Error executing '$HOME/.vscode-server/data/User/globalStorage/haskell.haskell/haskell-language-server-wrapper-1.4.0-linux --project-ghc-version' with error code 1
[client][ERROR] stderr: Found "$HOME/hie.yaml" for "$HOME/a"
Cradle requires cabal but couldn't find it
Cradle {cradleRootDir = "$HOME", cradleOptsProg = CradleAction: Cabal}

[July541]

I think it is caused by different versions between ghc and HLS, I see your HLS is compiled for 8.10.7, but your exposed ghc is 9.0.1, so vscode tried to download HLS for 9.0.1.

But I still remember HLS will raise an error directly if incompatible rather than download a new one...

[mixphix]

Unfortunately the same error occurs regardless of the GHC version I have marked "active" in GHCup, even if it does match the project version.

[mixphix]

UPDATE: It appears that when opening a single project's folder in VS Code the problem disappears.

[jneira]

thanks for reporting and the further investigation, will move to the extension repo

[jneira]

It would be great to get the extension log when the error is reproduced and hls starts to download hls...

[jneira]

This issue reminds me #492:

• It shows the Project requires GHC but it isn't installed error
• It is triggered when an instance of vscode is already running

[mixphix]

Further experimentation leads me to believe that where once, having a hie.yaml file in ~ (or whatever folder I open in Code-WSL) would "just work" -- HLS would find the projects' own hie.yamls as their files were opened -- now that seemed to be the cause of this issue. That is, having

cradle:
  cabal:

as the default hie.yaml in my Code-WSL ~ folder did not work, though I do the same on Code-Remote and with

cradle:
  stack:

which seems to work just fine.

[jneira]

And what is the behaviour without having any hie.yaml?

[mixphix]

Without a hie.yaml in ~, I do not see this error. :)

[fendor]

This should be resolved now by switching to ghcup. Feel free to reopen if the new extension doesn't fix the issue.