Option for automatic installation/change hls binary using ghcup

[Enayaaa]

Feature description

I have found myself jumping from cabal project to cabal project which do not use the same ghc version, this means that I need to change the hls version that is active via ghcup between every project. It would be nice if we could automatically install or at least choose a different hls version based on the project configs.

It does not make sense to install other binaries but if the user ensures that ghcup is available and configures haskell-tools to use automatic switching of hls version with ghcup this should be very useful.

This is a feature that the VSCode extension provides. It would be a nice life improving feature to have in haskell-tools.nvim as well.

[mrcjkb]

Hey 👋

Thanks for the request.

haskell-language-server already comes with a wrapper that does what you want.

This plugin tries to use the wrapper by default, but falls back to the haskell-language-server binary if it can't find it. In this case, you may just need to ensure that the wrapper is on the PATH, or configure his plugin to use it manually (:h haskell-tools.config and :h HaskellLspClientOpts).

[Enayaaa]

Thank you for clearing that up,I was not aware of that behaviour.

I think my issue has been that haskell-language-server-wrapper has not been able to detect the ghc version just from the cabal file (e.g. the entry tested-with: GHC ==9.2.8) and thus using the globally active ghc.

After some digging I found that the ghc version for my cabal project can be fixed with a cabal.project or cabal.project.local file with the config with-compiler: ghc-9.2.8.

Cheers :confetti_ball:

[Enayaaa]

Maybe I was too quick to celebrate actually, with some testing haskell-language-server-wrapper only supports a few ghc-versions, if it encounters a project with ghc version not supported by the currently active hls version then it breaks down.

I think this is the issue addressed by the VSCode extension I was talking about.

What would be nice in this case would be for haskell-tools.nvim to figure out the hls version that supports this ghc version and activate that with ghcup.

[mrcjkb]

Package management is beyond the scope of this plugin.

Unlike vscode-haskell, haskell-tools.nvim isn't opinionated about which toolchain is used to manage hls installations, or a hls installation even existing, for that matter.

For instance, I, and other users of this plugin, use nix devShells to manage hls, and sometimes want to be able to drop into a Haskell file without the LSP client starting up and complaining that it couldn't find an installation (but still use other things, like the repl and fast-tags). For this use case, vscode-haskell's behaviour would be quite inconvenient.

This plugin aims to adhere to the KISS principle. Making it behave like vscode-haskell would add a lot of complexity that ultimately wouldn't benefit many users (as neovim users tend to prefer more flexibility than vscode users).

Something like this would probably be the responsibility of another plugin, such as mason.nvim.