No ghc 8.8.3 support in the haskell-language-server package in nixpkgs

[JonathanLorimer]

Your environment

Output of haskell-language-server --probe-tools or haskell-language-server-wrapper --probe-tools:

haskell-language-server version: 0.8.0.0 (GHC: 8.10.3) (PATH: /nix/store/3c6i9fmv0s93q2jymvxd37nb3y2f8bzg-haskell-language-server-0.8.0.0/bin/haskell-language-server-wrapper)
Tool versions found on the $PATH
cabal:		3.0.0.0
stack:		2.5.1.1
ghc:		8.8.3

Which lsp-client do you use: Neovim
Describe your project (alternative: link to the project): package.yaml
Contents of hie.yaml:

cradle:
 cabal:
  - path: "./src"
    component: "lib:mwb"
  - path: "./test"
    component: "test:test"
  - path: "./app"
    component: "exe:mwb"
  - path: "./one-off-task"
    component: "exe:one-off-tasks"

I am getting an error that ghcide was compiled with 8.8.4 when my project uses 8.8.3. This is to be expected, but I am wondering if the pre-compiled binaries are missing 8.8.3 support?

running haskell-language-server-wrapper shows this:

Project GHC version: 8.8.3
haskell-language-server exe candidates: ["haskell-language-server-8.8.3","haskell-language-server-8.8","haskell-language-server"]
Launching haskell-language-server exe at:/etc/profiles/per-user/jonathanl/bin/haskell-language-server-8.8
haskell-language-server version: 0.8.0.0 (GHC: 8.8.4) (PATH: /nix/store/c8709i89qymkcpi6c2b1s3nlmj72b8gz-haskell-language-server-0.8.0.0/bin/haskell-language-server)

[jneira]

There is support for ghc-8.8.3 in the official release artifacts set: https://github.com/haskell/haskell-language-server/releases/tag/0.9.0
Not sure why it cant be available for nix though. @fendor and @pepeiborra are using nix iirc and maybe can help better than me

[Ailrun]

https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/tools/haskell/haskell-language-server/withWrapper.nix
This file in the nixpkgs repository lists the supported GHC versions.
You can change the supportedGhcVersions argument to whatever you want to make it built with different versions of GHC..

IDK why by default it supports only 8.6.5, 8.8.4, and 8.10.2 though...

[JonathanLorimer]

We could add more defaults, or add a section to the README explaining how to add support for different compiler versions. I can do either!

[JonathanLorimer]

I think I might have also found another related issue. I think you can only have 1 patch version for every minor ghc release. When I do this overlay hls fails to build:

(self: super: {
  haskell-language-server =
    super.haskell-language-server.override {
      supportedGhcVersions = [
        "865"
        "883"
        "884"
        "8102"
      ];
    };
})

with this error:

error: --- Error ---------------------------------------------------------------------------------- nix
builder for '/nix/store/bvbz959l8jvh0j264b9id1z9hyxzs8sg-haskell-language-server-0.8.0.0.drv' failed with exit code 1; last 1 log lines:
  ln: failed to create symbolic link '/nix/store/811v2z81is5h02cc8066v0ja338viysj-haskell-language-server-0.8.0.0/bin/haskell-language-server-8.8': File exists

but when I comment out one of the 88x versions everything builds just fine.

This is probably an issue with the nix-expression for haskell-language-server

[Ailrun]

Yes, since when you install both "883" and "884", it will try to install haskell-language-server-8.8 twice, as both of them are under minor version 8.8. I don't know what kind of preference (since those two haskell-language-server-8.8 are different binaries) should be given for such a case though...

[maralorn]

This is probably an issue with the nix-expression for haskell-language-server

Yep, it is! We should have an issue for this on nixpkgs. Mention me, as I am the author of that expression.
I think I ignored the problem because I couldn‘t think of a good solution. But I think the best solution is to let the newest version win.

Is there anything else to be fixed here? If not I suggest migrating the issue to nixpkgs and closing it here?

[maralorn]

IDK why by default it supports only 8.6.5, 8.8.4, and 8.10.2 though...

The reason is simply, that I didn‘t think that a lot of people use out-dated minor versions. But if they do, they have already opted into building a lot of stuff by themselves. Everything we enter by default will be built on hydra and increase the closure of the hls package, which is a lot of unnecessary balast for most users. So that’s the compromise we settled on. Should we reconsider that?

EDIT: I think it’s different for the binary distribution. It’s not very easy for users to switch from a provided binary to an unprovided version, because then they need to setup the build. So providing all versions there is a good idea. For nixpkgs users the difference is just if they can get the version from the binary cache or if they compile it themselves, but there is no additional knowledge or human work required other than understanding the documentation. So I think striking this ompromise makes sense in nixpkgs.

I have documented everything at: https://haskell4nix.readthedocs.io/nixpkgs-users-guide.html#how-to-install-haskell-language-server
I don‘t know how much of that should be copied to the hls README or if it should just be referenced. If anyone things anything in the documentation should be expanded, please tell me.

[jneira]

It seems nothing left to do here in the hls side, feel free to reopen in other case