Compiling HLS with custom bindist creates haskell-language-server-<ghcver>-<customtag>.exe shim and HLS fails

[jasagredo]

After compiling HLS for my 9.6.6-patched GHC (see #1149), the process terminates succesfully:

Copying 'haskell-language-server.exe' to
'C:\ghcup\tmp\ghcup-2e4270a6ac1940a3\haskell-language-server-2.9.0.1\out\9.6.6-patched\haskell-language-server.exe'
Copying 'haskell-language-server-wrapper.exe' to
'C:\ghcup\tmp\ghcup-2e4270a6ac1940a3\haskell-language-server-2.9.0.1\out\9.6.6-patched\haskell-language-server-wrapper.exe'
Copying 'ghcide-bench.exe' to
'C:\ghcup\tmp\ghcup-2e4270a6ac1940a3\haskell-language-server-2.9.0.1\out\9.6.6-patched\ghcide-bench.exe'
[ Info  ] Installing HLS
[ Info  ] HLS successfully compiled and installed
2.9.0.1Success
[ Info  ] downloading: https://raw.githubusercontent.com/haskell/ghcup-metadata/master/ghcup-0.0.8.yaml as file C:\ghcup\cache\ghcup-0.0.8.yaml
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
Press enter to continue

There is no haskell-language-server-9.6.6.exe binary, but there is a haskell-language-server-wrapper.exe which fails because the former is missing:

➜ ls /c/ghcup/bin/haskell-language* -l
-rwxr-xr-x 1 Javier Javier    115712 May  6  2024 /c/ghcup/bin/haskell-language-server-9.6.6-patched.exe
-rw-r--r-- 1 Javier Javier        69 Nov 11 10:07 /c/ghcup/bin/haskell-language-server-9.6.6-patched.shim
-rwxr-xr-x 1 Javier Javier 532895232 Nov 11 10:07 /c/ghcup/bin/haskell-language-server-9.6.6-patched~2.9.0.1.exe
-rwxr-xr-x 1 Javier Javier    115712 May  6  2024 /c/ghcup/bin/haskell-language-server-wrapper.exe
-rw-r--r-- 1 Javier Javier        63 Nov 11 10:07 /c/ghcup/bin/haskell-language-server-wrapper.shim
-rwxr-xr-x 1 Javier Javier 394523136 Nov 11 10:07 /c/ghcup/bin/haskell-language-server-wrapper-2.9.0.1.exe

➜ haskell-language-server-wrapper
Found "C:\Users\Javier\code\project\hie.yaml" for "C:\Users\Javier\code\project\a"
Run entered for haskell-language-server-wrapper(haskell-language-server-wrapper-2.9.0.1.exe) Version 2.9.0.1 x86_64 ghc-9.6.6
Current directory: C:\Users\Javier\code\project
Operating system: mingw32
Arguments: []
Cradle directory: C:\Users\Javier\code\project
Cradle type: Cabal

Tool versions found on the $PATH
cabal:          3.12.1.0
stack:          3.1.1
ghc:            9.6.6


Consulting the cradle to get project GHC version...
2024-11-11T09:09:13.121493Z | Debug | cabal exec -v0 -- ghc --print-libdir
2024-11-11T09:09:23.647506Z | Debug | cabal exec -v0 -- ghc -package-env=- -ignore-dot-ghci -e Control.Monad.join (Control.Monad.fmap System.IO.putStr System.Environment.getExecutablePath)
2024-11-11T09:09:29.597046Z | Debug | cabal --builddir=C:\Users\Javier\AppData\Local\hie-bios\dist-project-0b0ebd4d52f9efb7adc911c1cfe3dd69 v2-exec --with-compiler C:\Users\Javier\AppData\Local\hie-bios\wrapper-340ffcbd9b6dc8c3bed91eb5c533e4e3.exe --with-hc-pkg C:\ghcup\ghc\9.6.6-patched\bin\ghc-pkg-9.6.6.exe ghc -v0 -- --numeric-version
  Environment Variables
    HIE_BIOS_GHC: C:\ghcup\ghc\9.6.6-patched\bin\ghc-9.6.6.exe
    HIE_BIOS_GHC_ARGS: -BC:\ghcup\ghc\9.6.6-patched\lib
Project GHC version: 9.6.6
haskell-language-server exe candidates: ["haskell-language-server-9.6.6.exe","haskell-language-server.exe"]
Failed to find a HLS version for GHC 9.6.6
Executable names we failed to find: haskell-language-server-9.6.6.exe,haskell-language-server.exe

My understanding is that compiling HLS should create a haskell-language-server-<ghcver>.exe even if the custom ghc has a tag at the end, otherwise HLS-wrapper won't be able to find it.

Manually creating the shim works:

➜ cp haskell-language-server-9.6.6-patched.exe haskell-language-server-9.6.6.exe
➜ cp haskell-language-server-9.6.6-patched.shim haskell-language-server-9.6.6.shim
➜ haskell-language-server-wrapper
...
haskell-language-server exe candidates: ["haskell-language-server-9.6.6.exe","haskell-language-server.exe"]
Launching haskell-language-server exe at:C:\ghcup\bin\haskell-language-server-9.6.6.exe
2024-11-11T09:17:24.638034Z | Info | haskell-language-server version: 2.9.0.1 (GHC: 9.6.6) (PATH: C:\ghcup\bin\haskell-language-server-9.6.6-patched~2.9.0.1.exe)
...

[hasufell]

My understanding is that compiling HLS should create a haskell-language-server-.exe even if the custom ghc has a tag at the end, otherwise HLS-wrapper won't be able to find it.

I don't see how that can work. You'd potentially overwrite another version.

The problem generally is that there is a discrepancy between ghc version in GHCup and ghc --numeric-version. HLS uses the latter, afaiu. I don't know how to solve this.

[hasufell]

@fendor maybe has an idea

[fendor]

We encountered a similar issue with the same root cause in haskell/vscode-haskell#1151.

Afaik, there is no way to trick HLS-wrapper to do what you want in this case, unfortunately. The simplest workaround is to instruct your editor to simply launch the correct HLS binary.

However, this general workflow is quite interesting for testing changes, perhaps we can teach the wrapper to be aware of potential additional suffixes?
For example, hls-wrapper-<custom> could always look for hls-<ghc-version>-<custom>? However, when a user would still need to point the editor to the custom wrapper binary.

Alternatively, we could try to patch the shim to additionally look for hls-<ghc-version>-<custom> binaries. Assuming, we can get the <custom> part somehow out of the GHC binary.

[jasagredo]

Perhaps this also happens on Linux?

I'm not sure anymore if this issue belongs to GHCup or to HLS, but perhaps it is worth some note in GHCup when installing a custom HLS?

[fendor]

Perhaps this also happens on Linux?

I believe so, yeah.

It is a joint issue, I believe, the solution needs to be implemented in HLS, but for the best UX we need to coordinate.

What do you think about the proposed solution? Do you think having a custom hls-wrapper-<custom> binary which you have to manually tell your editor to use is feasible?

[jasagredo]

I think that should be fine. Most editors allow you to specify the binary to be used.

[fendor]

Thinking about it, if you can specify the binary, you could also simply specify the binary you built with the custom ghc as well, right? Simply avoid the hls-wrapper altogether?

[hasufell]

What do you think about the proposed solution? Do you think having a custom hls-wrapper- binary which you have to manually tell your editor to use is feasible?

Non-numeric versions are a hack (or leniency) of GHCup.

I do not think HLS should do anything here. I'm also not sure this edge case is interesting enough to dream up a solution.

I do think we could send a post-install warning message in GHCup if we detect such an oddly named hls-wrapper binary.