Nix installation?

[spacekitteh]

Anyone have a nix expression to install this?

[shajra]

I've got Nix expressions building Linux and Mac binaries with GitHub Actions and cached to shajra.cachix.org for 8.6.5, 8.8.4, and 8.10.2: https://github.com/shajra/nix-hls/actions/runs/252124388.

the README is not fleshed out, but my goal is to make clear instructions to get people started and point them in the right direction.

This is a Haskell.nix build, because I think trying to do it the Nixpkgs way is just a bit more tedious than it's worth. But if more GHC targets get compiled for Nixpkgs, then I guess the value of this project attenuates and binaries will be cached in Hydra (which is generally better).

[peterstorm]

@peterstorm If you still have this issue, try

# { stdenv
# , autoPatchelfHook
# }:
with import (import ./nix/sources.nix).nixpkgs {};
stdenv.mkDerivation {
  name = "haskell-language-server";
  src = fetchurl {
    url = "https://github.com/haskell/haskell-language-server/releases/download/0.4.0/haskell-language-server-Linux-8.6.4.gz";
    sha256 = "0fhzm9190mgya08mcjz9zrd34p1s3k1a1l9dzxpxm7ij9b43n333";
  };
  nativeBuildInputs = [
    autoPatchelfHook
  ];

  buildInputs = [
    git
    gmp
    ncurses
    zlib

    haskellPackages.cabal-install
    haskellPackages.hlint
  ];

  phases = ["installPhase"];

  installPhase = ''
    mkdir -p $out/bin
    gzip -d < $src > $out/bin/haskell-language-server-Linux-8.6.4
    chmod +x $out/bin/haskell-language-server-Linux-8.6.4
  '';
}

I ended up doing this stupid thing (https://github.com/peterstorm/blog/blob/master/nix/hls.nix), which works, but is convoluted - your's is way more succint, so I'll try that! :D

[masaeedu]

I feel bad for just making another thing instead of using one of the nice projects mentioned above, but I just wanted an easy way to consume the Github releases of this project (instead of using something built from source somewhere else).

I wrote a script yesterday that extracts all the version platform combinations of the HLS wrapper and the GHC-specific HLS binaries into a structured blob of JSON. Then I added a Nix expression that takes a desired platform (i.e. macOS or Linux), version and GHC and just gunzips the correct wrapper and GHC-specific binary from the Github releases into a derivation.

In your shell.nix, you can have:

with import <nixpkgs> {};

let
  all-hls = fetchFromGitHub { owner = "masaeedu"; repo = "all-hls"; rev = "155e57d7ca9f79ce293360f98895e9bd68d12355"; sha256 = "04s3mrxjdr7gmd901l1z23qglqmn8i39v7sdf2fv4zbv6hz24ydb"; };
  hls = import all-hls { version = "0.4.0"; ghc = "8.6.5"; };
in
mkShell {
  buildInputs = [ hls ];
}

And then run:

➜  aijdoadasoidsa nix-shell

[nix-shell:/tmp/aijdoadasoidsa]$ haskell-language-server --version
haskell-language-server version: 0.4.0.0 (GHC: 8.6.5) (PATH: /nix/store/dhnghmpz1c9gz8rjpyj2vikxr93f569g-haskell-language-server-0.4.0-for-8.6.5-on-Linux/bin/haskell-language-server) (GIT hash: 0a18edde24923251a148cbbc0ae993a6aac83b9c)

You can find the script, JSON, Nix expression here: https://github.com/masaeedu/all-hls

[shajra]

Okay, it's good that people figured out how to wrap the published HLS builds. Hopefully that can also get cached into Cachix too. In the meantime, I think my nix-hls project still might have some reason to exist (maybe not much), because by building from scratch, I can build the unreleased versions too if there's some motivation to do that (like a work-around to a bug).

I didn't get around to writing docs for it this weekend, but when I do I have a personal note to reference the other projects mentioned in this thread so people know what their options are.

[korayal]

Is there a way to have a haskell-language-server-wrapper executable that can work out what version of GHC the project uses, and runs it's respective haskell-language-server executable on Nix?

[GuillaumeDesforges]

Is there a way to have a haskell-language-server-wrapper executable that can work out what version of GHC the project uses, and runs it's respective haskell-language-server executable on Nix?

I was just on my way to signal that https://github.com/NixOS/nixpkgs/pull/99519 has been merged, so wrapped hls will soon land on nixpkgs unstable.

[jneira]

When the nix installation will be stable enough it would be great to add a section about in README (and close the issue). pr's welcome! 😄

[maralorn]

There is an attribute pkgs.haskell-language-server in nixpkgs unstable (as soon as unstable has passed the tests, see: https://status.nixos.org/), that should "just work".

I also added a section to the nixpkgs manual on how to install and run hls. If I don‘t forget it I can post a link here once the channel bump happened.

EDIT: I will post here, once hls has really entered unstable.

[sgraf812]

Apparently, the commit landed and the tests were green at least once in the last few weeks. There's https://haskell4nix.readthedocs.io/nixpkgs-users-guide.html#how-to-install-haskell-language-server that describes how to install HLS. As far as I can tell, it works! Thank you :)

[maralorn]

Oh, yeah. I forgot about this thread.^^ Thanks, for the link @sgraf812 .

I have gotten positive feedback about it, but I would be glad to hear about any troubles. This concerns the actual package as well as the documentation.

[domenkozar]

FYI: I've seen ghcide/HLS segfault on Nix when using TH https://github.com/haskell/ghcide/issues/910

[tscholak]

Maybe a bit OT, but for those of you using IOHK's haskell.nix, I can recommend adding hls as a "tool" to the shell derivation like so: https://github.com/hasktorch/hasktorch/blob/0ba5db83111c7fa4e5a6c32d83cbadbca36120c9/nix/default.nix#L39. Works very well 😀

[maralorn]

I am using hls on nix with TH and I haven‘t witnessed any segfaults yet (although I had two other TH issues which were fixed in the meantime).

I thought I had heard other reports about TH segfaults. Would be interesting to know if those also only happened on nix.

[domenkozar]

I have a feeling that it's glibc difference between my system and what ghcide/HLS was compiled with, given that dlopen is part of stack trace.

In this particular case, if I compile HLS via stack+nix (which takes my local system NIX_PATH) it works.

[maralorn]

@domenkozar So you think you get the crashes because you use hls from unstable on a stable-nixos system or something similar?

I wonder how they could possibly interact.

[domenkozar]

That's my assumption, but I didn't confirm it. I don't think there's a way to tell haskell packages in nixpkgs to build everything with debug symbols, that would at least help pin down full trace.

[domenkozar]

Should we close this with README update how to install HLS with Nix by pointing to https://haskell4nix.readthedocs.io/nixpkgs-users-guide.html?highlight=language%20server#how-to-install-haskell-language-server ?

[shajra]

A while ago, I committed to maintaining some Haskell.nix-based builds of HLS. I also put in a good amount of documentation on using HLS with Nix. I like where it ended up. However, if this documentation is useful, I wonder if it's too much on-the-side and hidden away.

I'd appreciate people's review and suggestions: https://github.com/shajra/nix-haskell-hls

[spacekitteh]

@domenkozar I'm more than happy to close it, but I obviously can't update the README, so someone should do that and close it in the commit.

[jneira]

@domenkozar I'm more than happy to close it, but I obviously can't update the README, so someone should do that and close it in the commit.

a pr will be very very welcomed

[jkachmar]

I threw together a small project in the vein of Justin Woo's easy-dhall-nix and easy-purescript-nix, which reuses the binaries produced by this repository's release page to produce installations that are compatible with Nix.

https://github.com/jkachmar/easy-hls-nix

---

I've tested this (manually) on both macOS and NixOS installations, and if there's interest I can polish it up a bit more with some sort of CI setup that can check the results and perhaps automate things whenever this project pushes a new release.

[masaeedu]

@jkachmar I posted this earlier in the thread, so you might already have looked at it, but you might find https://github.com/masaeedu/all-hls interesting.

[maralorn]

@jkachmar Have you tried that with a little more complex projects? e.g. with TH? I looked at your project and the amount of magic your doing is so small that I would be surprised if that worked for all cases.

[jkachmar]

@masaeedu I hadn't seen that (I confess that I didn't read through the thread in its entirety before posting my repo), but I like your solution quite a bit! It's nice to have an option that provides access to all of the prior versions based on user-selection, thanks for point it out.

---

@maralorn I haven't tried it with more complex projects, but if someone has a reproducible case of the TH issues that people have seen in the past with HLS and Nix I'd be willing to take a look at it.

From my (brief) reading on this, though, it seems like the TH issues are more likely to be a problem with how HLS and Nix interact with each other; I'd be surprised if it's something that could be solved by building the executables differently.

[maralorn]

@jkachmar Well, I don‘t remember exactly. There were numerous TH issues.

What I am thinking about are I think linking issues. From my experience not using the same ghc to compile hls and your project will lead to issues in nixpkgs. That e.g. happens when dependencies build with cabal are linked against different glibc versions than hls. Sometimes stuff like that surfaces when using TH but maybe I just misremember that.

But if @masaeedu has also using this approach then maybe this is just fine?

I am really surprised by this. I was under the impression that the static binaries wouldn‘t be compatible … Doesn‘t this mean that the vscode plugin which just dynamically downloads hls binaries for you should work just fine under nixos?

[maralorn]

@jkachmar I went back and tested three things on my project: a) Using the vscode plugin on my codebase without any hls installed. b) Using your package to install hls. c) Use the hls from nixpkgs.

In the cases a) and b) I get

Message:  Unexpected usage errorld-linux-x86-64.so.2: cannot open shared object file

(accidentally all the files I get this error in use TH.) It’s not exactly the error I had expected, but it’s a linking problem, so I am not surprised.

With c) it works.

So as cool and simple as your approach it, I fear it’s not a general solution.

[jkachmar]

@maralorn I've opened a Draft PR with a workaround for NixOS that I believe should fix this issue.

I added a small test to check that basic Template Haskell invocations work (e.g. aeson), but I'm not sure if there's some edge case that I haven't accounted for.

[jneira]

Hey, i think we could transform the wisdom put in this issue in some document, f.e. a guide to:

• install/setup a dev env for hls using nix
• how to use hls in nix environments

It seems there are several methods to do it. someone has the opportunity to write something alike (or part of it)?

[maralorn]

@jneira For us nixpkgs Haskell maintainers, documentation is the next thing on our todo list. Setting up a dev environment will be central in that and using hls will again be central in that.

[domenkozar]

Note that I can't upgrade to 1.4.0.0 because it requires a nixpkgs-unstable to get GHC 8.10.7 while my system runs stable 21.05.

As my project uses TH, as soon as HLS typechecks my project then segfaults while calling dlopen. It seems that glibc mismatch between how HLS is compiled and system makes it segfault, but that's just a wild guess.

[jkachmar]

@domenkozar If you’re using the statically linked version then yeah this is a known consequence of statically linking against glibc.

As I understand it, there’s no guarantee of stability for the interpreter between any version of glibc, so the statically linked HLS binaries rely on the fact that most users will likely be invoking it on a distribution that has a compatible version of glibc.

---

Possibly veering off topic a bit, but I really don’t think HLS should be packaged this way.

If we want a statically linked executable then we should use musl, otherwise we should at most only be partially statically linking the executable (i.e. not statically linking glibc).

[pepeiborra]

Possibly veering off topic a bit, but I really don’t think HLS should be packaged this way.

If we want a statically linked executable then we should use musl, otherwise we should at most only be partially statically linking the executable (i.e. not statically linking glibc).

I would fully support a PR that did this

[domenkozar]

@domenkozar If you’re using the statically linked version then yeah this is a known consequence of statically linking against glibc.

As I understand it, there’s no guarantee of stability for the interpreter between any version of glibc, so the statically linked HLS binaries rely on the fact that most users will likely be invoking it on a distribution that has a compatible version of glibc.

Possibly veering off topic a bit, but I really don’t think HLS should be packaged this way.

If we want a statically linked executable then we should use musl, otherwise we should at most only be partially statically linking the executable (i.e. not statically linking glibc).

It's compiled using stack build --stack-yaml=stack-8.10.7.yaml. Using one from nixpkgs also doesn't work.

Don't think the problem is in static linking of HLS but rather TH and glibc mismatch

[jneira]

This issue is deeply buried in the issue tracker and i think there are lot of valuable info here that worths to be included in the installation guide https://haskell-language-server.readthedocs.io/en/latest/installation.html Someone volunteer? @michaelpj :wink: ?

[maralorn]

I had written everything, that I thought was necessary about this in https://haskell4nix.readthedocs.io/nixpkgs-users-guide.html#how-to-install-haskell-language-server, which will hopefully soon move into the nixpkgs manual.

I suggest that both documentations reference each other. I don‘t care very much, where the meat of the content resides.

[jneira]

wow, wonderful, thanks for the info, will link it in our docs

[jneira]

2256 will close this epic issue, very much thanks to you all

[michaelpj]

To add a late addition: HLS is pretty easily buildable with haskell.nix, by pointing it at the HLS repository and using cabalProject.

[maralorn]

Cool! For anyone stumbling by I want to point out: Get your hls from where you get your ghc. If you install ghc from haskell.nix then do as Michael says. If you install ghc from nixpkgs follow the nixpkgs manual at: https://nixos.org/manual/nixpkgs/unstable/#haskell-language-server Mixing things is not supported and will very likely fail totally or in confusing ways.