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

[michaelpj]

I hate it when tools try and automatically install things. Inevitably it ends up becoming a (bad) package manager that doesn't interact well with the user's existing package management solutions, is opaque, and provides another source of unpredictable behaviour. I would also want to disable this immediately.

However.... people do seem to really like the automatic installation of HLS by the vscode extension. So I concede that I evidently am not a 100% representative user :) Perhaps we should ask some of our users whether they would want this?

[hasufell]

dont we want to offer the same experience for sublime, emacs or vim people with only switching a flag?

I don't think so. VSCode users and vim users have vastly different expectations. Vim users micro-manage their plugins and settings.

[jneira]

Ok @michaelpj @hasufell i've updated the description with the different alternatives and discarding being opt-out, which would be your preferred one?

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

Note i've pointing out some caveats here: #2251 (comment)

[jneira]

I don't think so. VSCode users and vim users have vastly different expectations. Vim users micro-manage their plugins and settings.

sure, i dont think vim plugin will use the feature but maybe the other ones (not sure about emacs but sublime and kakoune might do)

[hasufell]

1. and 2. are fine. If you go for 2. I'd make sure that it's opt-in... e.g. a one-time plugin popup if a GHC version is missing asking whether you want to opt-in.

[michaelpj]

Yes, in fact what had occurred to me is that really this is something where you want to ask the user what they want upfront. I think the vscode extension just does it right now rather than asking, right?

Something like: "Can't find a haskell-language-server installed for this project. Would you like to a) install and configure it yourself? b) install it automatically with ghcup? You can change your preference later in the settings."

If we then had something similar for installing GHC I wouldn't hate it, I guess.

[jneira]

1. and 2. are fine. If you go for 2. I'd make sure that it's opt-in... e.g. a one-time plugin popup if a GHC version is missing asking whether you want to opt-in.

And download cabal or stack if the project needs one of them?

[jneira]

Something like: "Can't find a haskell-language-server installed for this project. Would you like to a) install and configure it yourself? b) install it automatically ghcup? You can change your preference later in the settings."

Right now the extension downloads hls-wrapper and hls by default if it is not in PATH and the config option with a explicit path to hls is not set. And you can even disable it entirely. There is no much other ways to tell the extension where hls is placed so i think is fine to download it by default in that case but asking a one-off question to set the configuration could be done as @hasufell suggested. It doesnt use ghcup for now.

I would do the same for ghc/cabal/stack with an one-off question (using ghcup to leverage its install logic, will be crazy to reimplement it twice). I would use ghcup to install hls itself if ghcup is in PATH, preserving for now the actual behaviour.

[jneira]

Ok, we are all experienced haskellers who like to have control over our setup. I would like to read more opinions about, reflecting the beginners point of view. Well sure there are beginner who will want to control it anyways.

//cc @Ailrun @berberman @ndmitchell

If nobody disagree will move this to the vscode extension project, to implement there the download of the toolchain using ghcup.

[jneira]

Ok no beginner came here to give its point of view 😝 so i am gonna move this to the vscode extension, thanks all for the feedback!