Make sure that the installed GHC version is supported by HLS

[mardukbp]

As a complete Haskell newbie I used GHCup to install GHC, Stack and HLS on Ubuntu.
I created a new project with Stack, opened it on VS Code and the Haskell Language Server could not start. The reason is that GHCup installs GHC 9.2.8, which is not supported by HLS. Whereas 9.2.7 is. This information is known to GHCup as seen in the TUI.

My suggestion is that if during installation the user chooses to install Haskell Language Server, then GHCup should install a version of GHC compatible with HLS. However, this does not solve the problem. Because stack new also uses the latest LTS Snapshot. Therefore, it would be necessary to configure the resolver url in ~/.stack/config.yaml, either automatically (during installation) or manually (by instructing the user how to do it).

I believe that the current behavior makes getting started with Haskell unnecessarily complicated. GHCup should setup a development environment that works out of the box.

[arjunkathuria]

Hi @mardukbp, thanks for raising the issue.

GHCup should setup a development environment that works out of the box.

I agree, from an experience perspective everything working out-of-the-box for first time installs is indeed nice.

iirc the first install installs the recommended version of tools. Sometimes the point releases of GHC contain some important fixes, which make them the recommended version, while the HLS support for them may take time to catch up (its usually the next release).

As an alternative in the meanwhile, one can:-

1. compile HLS for the new point ghc version with a simple one-liner ghcup command. ghcup compile hls -g 2.0.0.0 --ghc 9.2.8 --cabal-update
2. manually install / set an older ghc point version.

There's a helpful message indicating this when installing a GHC without HLS support (in the installer terminal output in yellow color), can't recall if this is shown at first install though:-

[ Warn  ] GHC-9.2.8 appears to have no corresponding HLS-1.10.0.0 binary.
[ ...   ] Haskell IDE support may not work.
[ ...   ] You can try to either: 
[ ...   ]   1. Install a different HLS version (e.g. downgrade for older GHCs)
[ ...   ]   2. Install and set one of the following GHCs: [9.6.1, 9.4.4, 9.2.7, 9.0.2, 8.10.7]
[ ...   ]   3. Let GHCup compile HLS for you, e.g. run: ghcup compile hls -g 1.10.0.0 --ghc 9.2.8 --cabal-update
[ ...   ]      (see https://www.haskell.org/ghcup/guide/#hls for more information)

@hasufell is usually conservative in bumping the recommended versions and there's almost always a good reason, esp if it breaks HLS compatibility.

[hasufell]

The idea was to make a quick HLS release after: haskell/haskell-language-server#3608

This got delayed by CI issues and my laptop is now in repair.

The Haskell toolchain has an issue with bus factor. I'm an unpaid volunteer.

[mardukbp]

@arjunkathuria Thank you very much for the thorough response.

IMHO compiling software is a no-go when you just want to set up a dev environment and get things done. And this comes from someone who has compiled X11, GraalVM, and lots of other projects. I know it takes time and effort (because something can go wrong and the compiler messages might not be very helpful). It is easier to just downgrade GHC.

The warning message you pointed out is indeed shown the first time that GHCup is installed. Thank you. I did not notice it because it is printed immediately after the installation of HLS and then more stuff is printed to the console and I only read the final message with the instructions to get started.

I would suggest collecting all the warnings and showing them at the end for increased visibility. And like I said in my first message a notice along the lines of: "When creating a new project stack will use the latest LTS, which might be incompatible with the installed version of HLS. You can configure the resolver url either in the global stack configuration or project-wise." would also be helpful.

I am sure there are good reasons for designating a GHC release as the recommended version. But I think that a functioning dev environment should have a higher priority than having the latest improvements from a patch version.

@hasufell Of course I am aware that open-source projects are mostly driven by unpaid volunteer work. I am very grateful for the time and effort that you give to the Haskell community! As you said a lot of things have to go right in order for the release cycle to work smoothly. And sh*t happens. That is why I would recommend to upgrade a multi-component project only after its dependencies have been upgraded. Ideally every release should be fully functioning.

Please note that I am not complaining or demanding anything. I just want to contribute to make the entry barrier to Haskell as low as possible.

[hasufell]

I am sure there are good reasons for designating a GHC release as the recommended version. But I think that a functioning dev environment should have a higher priority than having the latest improvements from a patch version.

This is already policy in GHCup. But policies need to be adhered to. Sometimes we don't, for no particular reason or because coordination wasn't on point.

[mardukbp]

I see. Is it something that can be improved with automation? Or maybe with a four-eyes release approval? I don't want to make anybody's life harder. I am just curious. I know this also happens in companies and I would like to know what people with more experience than me would do :)

[hasufell]

Is it something that can be improved with automation?

Don't think so. Release management is hard. Especially when it's across multiple tools.

My employer doesn't support my open source activities.

Our open source performance depends on motivation, stress levels and processes.

[mardukbp]

Fair enough. You do the best you can. Thank you for your great work!