Download required haskell toolchain via ghcup in hls-wrapper

[jneira]

• To complete the initial experience with haskell including hls we could add the possibility of download the required and missing haskell toolchain in hls-wrapper, using the info from the project or file from hie-bios
• ghcup is the unique haskell installer which cover the default toolchain for all major oss: ghc, stack and cabal
• Cases:
  • missing haskell-language-server: ghcup install hls. It will install another hls-wrapper which maybe will replace the used one. To consider.
    • maybe we could warn users about
  • cabal cradle: do a ghcup install cabal && ghcup install ghc ${version}, where ${version} will be the ghc version reported by the cradle or empty if it is not known, after downloading cabal itself (needed for query the ghc version)
    • it will download only the missing tool, cabal or ghc
  • stack cradle: do a ghcup install stack and let stack download the rest of needed tools (as with the default stack via ghcup will download ghc and/or msys2 in its own)
  • direct cradle: do a ghcup install ghc
  • bios cradle: do nothing
• We have to decide what to do if ghcup itself is missing:
  • do nothing
  • download ghcup
  • suggest user install it
• The feature will be triggered by default and disabled with --no-download-haskell-toolchain The feature will be disabled by default and enabled with --download-haskell-toolchain

Alternatives:

1. do nothing, let users install the toolchain as they wish
2. implement it only in the vscode extension (using ghcup)
3. implement hook in hls-wrapper and provide a default one in vscode
4. implement it opt-in in the hls-wrapper

//cc @hasufell

[hasufell]

I can only speak for myself, but one of the reasons ghcup was written is that people disliked the automatic downloading of GHC versions from stack.

If haskell-language-server-wrapper would start doing that, I'd want to disable it on all my systems.

IMO, tools work best if there's a tree-style hierarchy: e.g. you wouldn't expect gcc to call make, would you? Of course this isn't total and we always end up with some sort of graph. But the main point is giving users a predictable toolchain, at least in my opinion.

This could be another use case for hooks: if you start HLS and the required GHC version is missing, execute a given shell script with certain environment variables set. Similar to what I did for stack.

[jneira]

Possible caveats:

• maybe we will download the incorrect version of a given tool. For example, for opening a file or a direct cradle we could download a ghc version which could not support the haskell code
• we have to be careful with error handling
• we take a big responsability 😅

[jneira]

This could be another use case for hooks: if you start HLS and the required GHC version is missing, execute a given shell script with certain environment variables set. Similar to what I did for stack.

But we will have to take the decision if we use a default hook doing the installs, the difference would be you allow advanced user to implement its own hook (and no use ghcup for example 😝 ). The drawback is you have the code written in bash (and powershell if msys2 is not available) instead haskell. That feature is oriented to beginners as advanced users will have probably all the toolchain installed

Another option is make it opt in instead opt out. Will add a config option in the vscode extension anyways.

you wouldn't expect gcc to call make, would you?

but hls will not call ghcup, hls-wrapper will do so the graph would be hls-wrapper -> ghcup -> hls. We will use the existing ghcup to do it so it would be a handy shortcut in that case.

[hasufell]

The drawback is you have the code written in bash

That's not a drawback for hooks. It's much simpler, because it doesn't need recompilation if you change a single line. Also, hooks are usually low complexity, there's little advantage in using haskell for this. You'll just make it extra hard for users to change it.

At any rate, I don't think it's HLS job to install a toolchain at all. I'm sure most people don't start with Haskell by installing HLS, but by installing GHC.

[hasufell]

Also, you're going to conflict with stack installing GHC automatically and possibly with cabal if it ever implements user hooks.

So I don't think this is a good idea.

[jneira]

That's not a drawback for hooks. It's much simpler, because it doesn't need recompilation if you change a single line. Also, hooks are usually low complexity, there's little advantage in using haskell for this. You'll just make it extra hard for users to change it.

Hook could be included as a first try if it exists (like in stack which will download ghc anyways if the hook is not present)

The motivation will be download it for beginners who dont know much about stack, cabal or ghc and nothing about hooks.
If we use a default hook with the described behaviour there will be no functional difference.

[jneira]

I'm sure most people don't start with Haskell by installing HLS, but by installing GHC.

Not sure about that, i think people is starting to use haskell via vscode and the extension and they hit the missing toolchain.

[jneira]

Also, you're going to conflict with stack installing GHC automatically and possibly with cabal if it ever implements user hooks.

As stated in the descfription we would let stack download ghc and msys2 in its own.
Conflict with cabal user hooks is a good point but not sure if that will be implemented at short/mid range.
And. well, the hls hook will have conflicts with the cabal hook, right? If we provide a default hook it will be our responsability as well.

[jneira]

dont want to enter the ongoing war about what tool is in the top of the haskell toolchain graph, though 😝

another alternative could do this in the vscode extension to isolate the feature, but i think make it opt-in int the hls-wrapper and make vscode use it by default (with an opt-out) will be equivalent (and we will not have to write typescript)

another one could be include hooks in hls-wrapper and use default ones in the extension

[jneira]

As we are watching lately to rust land is worth to note that the rust vscode extension only requires rustup to be installed and then uses it to download the rest of the toolchain with no alternative to use other ways.

[hasufell]

i think people is starting to use haskell via vscode

Then that means vscode should install GHC, not HLS.

As we are watching lately to rust land is worth to note that the rust vscode extension only requires rustup to be installed and then uses it to download the rest of the toolchain with no alternative to use other ways.

There's a difference between the vscode extension and the haskell-language-server-wrapper binary. A big one.

[jneira]

There's a difference between the vscode extension and the haskell-language-server-wrapper binary. A big one.

even doing it opt-in the wrapper? dont we want to offer the same experience for sublime, emacs or vim people with only switching a flag? it would be a little bit unfair for them or for plugin developers of such editors who will have to reimplement the logic