ghcup integration

[hasufell]

GHCup integration open questions

Scope

There are two main scopes afais:

1. ghcup installing hls
2. hls calling ghcup/relying on its files

GHCup installing hls

There are a number of unanswered questions:

1. What are the exact names of the executables to be installed?
2. How exactly does the wrapper script work?
3. Is it desirable that users can install different HLS versions and switch between them or should we assume the latest is always desirable (as is done for ghcup)?
   • If multiple versions, would the wrapper script be aware of qualified executable names? (e.g. hlswrapper-<hlsver> would use hls-<ghcver>-<hlsver>)
4. Should users be able to install for a specific GHC only or should the binaries for all GHC versions be installed?
   • If the latter, how do we make the supported GHC versions for hls visible?

Outstanding issues that need to be solved:

• hls --version does not work #238
• ghcup currently does not allow multiple downloads per tool. The most convenient way would be to pack a tarball, depending on the decision of point 4, that at least contains both the executable(s) and the wrapper script.

HLS calling/using ghcup

1. Should hls install GHC via ghcup?
   • and if so, in what location (this is configurable via env variable)
2. Are there any outstanding questions or issues?

My opinion on 1. is: rather not. It would be disruptive, but could be guarded with a config/cli switch. It could also be done in a different directory than ~/.ghcup to not collide.

[lukel97]

I kind of like the idea of option number two, which we could either integrate with the VS Code extension or the wrapper.
In the latter case the we could supercharge the wrapper and just have it download GHC, cabal, stack and hls binaries or whatever is needed.
Does there exist a command line option to change the install directory from ~/.ghcup to somewhere else? That would be very useful for the vs code extension where we could install it into the extension's specific storage directory

[fendor]

I do not think we should call ghcup from the wrapper or hls directly. Automagically installing everything could be very annoying for power users. Besides, it does not feel to me like the unix philosophy, too many responsibilties for HLS. Also, does the LSP protocol support such a workflow?
However, I think it would be nice to let the vscode extension use ghcup. This way we could have some non-lsp interaction before starting the language-server, e.g. asking the user to install ghc for them, etc...

[jneira]

I think it is inevitable that we will have to add vscode config options to tuning auto download: disable it entirely, customize the path where executables lives, etc
Please remember that any feature using ghcup will not be available for Windows and we should provide an alternative, using chocolatey for example?

[lukel97]

@jneira jneira we could check if chocolatey is installed and offer to install it. But I think the ideal scenario would be that GHC/cabal/stack gets installed somewhere in the vscode extension's globalStorage directory so it doesn't mess with the global install at all

[hasufell]

Does someone have information on my questions regarding ghcup installing hls?

[fendor]

I can give some answers:

1. The executables are currently named haskell-language-server and haskell-language-server-wrapper. Additionally, there can be a suffix for haskell-language-server for each ghc version, such as haskell-language-server-8.8.3.
2. The wrapper tries to find out the ghc version of the project you want to load. It does that by finding the appropriate build tool (via hie-bios) and then executes some build-tool specific logic to find the ghc to compile your project with. If it finds a ghc version , it first tries to launch haskell-language-server-<ghc-version> and if that is not found it defaults to "haskell-language-server".
   • The wrapper script can be compiled with any ghc version that is supported by HLS
   • Note that there are currently symlinks such as haskell-language-server-8.8 that point to haskell-language-server-8.8.3 (or the latest minor version) to which the wrapper can default to (The whole order is: "8.8.3" -> "8.8" -> no suffix). But since they apparently cause a lot of trouble, I think we should no longer install/symlink them
3. So far, we always assumed latest is the greatest. As a first step, in my opinion this is good enough. The wrapper script does not know about such a versioning scheme.
4. This is probably a UX decision. In my opinion, we should be able to install HLS per GHC version. Installing HLS for each supported GHC version will take up a huge amount of memory (my guess would be at least 2 GiB.)

[hasufell]

Ok, so my take is:

1. install for all available GHCs... no micro-management
2. only install one hls version (latest, like ghcup itself)
3. have a single tarball per platform (linux and mac) that has all hls binaries AND the wrapper script
4. make sure ghcup gives a proper indication on e.g. ghcup list which ghc versions are hls supported

Can anyone do the tarball part? (3.)

[hasufell]

I have implemented this here: https://gitlab.haskell.org/haskell/ghcup-hs/-/merge_requests/35

The file structure is as follows, please confirm this is correct:

$ ls -la ~/.ghcup/bin/haskell-language-server*
lrwxrwxrwx jule users    36 B    haskell-language-server-8.10.1 ⇒ haskell-language-server-8.10.1~0.4.0
.rwxrwxrwx jule users   123 MB   haskell-language-server-8.10.1~0.4.0
lrwxrwxrwx jule users    36 B    haskell-language-server-8.10.2 ⇒ haskell-language-server-8.10.2~0.4.0
.rwxrwxrwx jule users 124.2 MB   haskell-language-server-8.10.2~0.4.0
lrwxrwxrwx jule users    35 B    haskell-language-server-8.6.4 ⇒ haskell-language-server-8.6.4~0.4.0
.rwxrwxrwx jule users 130.1 MB   haskell-language-server-8.6.4~0.4.0
lrwxrwxrwx jule users    35 B    haskell-language-server-8.6.5 ⇒ haskell-language-server-8.6.5~0.4.0
.rwxrwxrwx jule users 130.1 MB   haskell-language-server-8.6.5~0.4.0
lrwxrwxrwx jule users    35 B    haskell-language-server-8.8.2 ⇒ haskell-language-server-8.8.2~0.4.0
.rwxrwxrwx jule users 121.3 MB   haskell-language-server-8.8.2~0.4.0
lrwxrwxrwx jule users    35 B    haskell-language-server-8.8.3 ⇒ haskell-language-server-8.8.3~0.4.0
.rwxrwxrwx jule users 121.3 MB   haskell-language-server-8.8.3~0.4.0
lrwxrwxrwx jule users    35 B    haskell-language-server-8.8.4 ⇒ haskell-language-server-8.8.4~0.4.0
.rwxrwxrwx jule users 121.3 MB   haskell-language-server-8.8.4~0.4.0
lrwxrwxrwx jule users    37 B    haskell-language-server-wrapper ⇒ haskell-language-server-wrapper-0.4.0
.rwxrwxrwx jule users   4.7 MB   haskell-language-server-wrapper-0.4.0

I uploaded preliminary tarballs here: https://files.hasufell.de/hls/

The contents of the per-platform tarballs must be as follows:

$ tar xvf haskell-language-server-Linux-0.4.0.tar.gz
haskell-language-server-8.6.4
haskell-language-server-8.6.5
haskell-language-server-8.8.2
haskell-language-server-8.8.3
haskell-language-server-8.8.4
haskell-language-server-8.10.1
haskell-language-server-8.10.2
haskell-language-server-wrapper

If this is all correct, someone should upload said tarballs to the release page, for Linux and mac.

[fendor]

Done:

[hasufell]

Done and released, thanks all!