Use hackage version of haskell-language-server

[hamishmack]

Removes the custom-tools as haskell-language-server is now in
hackage!

We considered also adding support for -wrapper, but decided it was better to fix emacs so that it works if just haskell-language-server is present.

[hamishmack]

bors try

[iohk-bors]

try

Build succeeded:

• buildkite/haskell-dot-nix
• ci/hydra:Cardano:haskell-nix:required

[michaelpj]

The new -wrapper tool is needed for emacs but not vscode

That's not true, you just change the server path in the emacs support (that's what I do already). So I don't think we need the -wrapper tool: just provide the binary and the client can sort the rest out.

[rvl]

The default value for lsp-haskell-server-path is haskell-language-server-wrapper, so if that is present on the PATH then emacs lsp can work with less customization. But as far as I know, the ghc version detection isn't really needed, so it could just be a symlink.

[michaelpj]

Exactly: if you're providing the right binary version in your nix-shell, you don't need the version detection.

This is IMO an issue with the emacs integration: we pick the default that works for people installing the "fat" bundle with the wrapper. Perhaps we should just fall-back to trying haskell-language-server if the wrapper isn't present. But regardless I don't think we should work around it here: if the user asks to install haskell-language-server, just install the binary they asked for!

[abailly]

From what @michaelpj says, do I understand correctly that with haskell-language-server defined in the tools set of the package, and assuming emacs picks up the correct environment from the nix-shell using eg. direnv, the wrapper is not needed and I can just configure lsp-haskell-server-path to be haskell-language-server which, by definition, will be the one built with the correct GHC version?

[michaelpj]

Exactly.

[hamishmack]

bors try

[iohk-bors]

try

Build succeeded:

• buildkite/haskell-dot-nix
• ci/hydra:Cardano:haskell-nix:required

[infinisil]

Note that this is backwards incompatible, because hackage versions are 0.8.0.0 or 0.9.0.0, whereas previously the custom tool definitions used the version format 0.8.0. So newly including haskell-language-server needs to be done like

shellFor {
  tools.haskell-language-server = "0.8.0.0";
}

instead

[vherrmann]

So, I had a very unpleasant experience the last two days. I had a multitude of issues that were very obscure and one of the problems was that emacs didn't use the right version of HLS. For quite some time I thought emacs or some of the packages (envrc-mode, inheritenv) are bugged (Wasted lots of time on this). Since I have haskell-language-server with its wrapper installed in my normal environment, emacs used the wrapper from outside of the haskell.nix environment, therefore the wrong version of HLS was used. Furthermore it was very intransparent to me for which reason emacs behaved differently in some projects, since my last project used the normal nix stack and with that emacs worked fine, since the normal nix stack shadows haskell-language-server-wrapper as well (Though I didn't realize this crucial difference until just now.).

So that this doesn't happen to others I think that e.g. haskell-language-server-wrapper should point to haskell-lang-server (Since that should be the version of HLS the user wants in a haskell.nix env) or there should be a giant warning in the docs. This could also be a malfunction of haskell-language-server-wrapper (since it should pick the right server from the environment?), though I'm not sure about that.