Nix installation?

[spacekitteh]

Anyone have a nix expression to install this?

[korayal]

When I have spare time, I try to keep up with the master branch for GHC 8.6.5 here: https://github.com/korayal/hls-nix It also has a cachix cache for darwin & linux

…

On Sat, May 23, 2020, 08:57 Sophie Taylor ***@***.***> wrote: Anyone have a nix expression to install this? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#122>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACMTSIMIE5E3K6KKNII7V3RS5QVVANCNFSM4NIJ3CYA> .

[414owen]

@korayal I tried out a bunch of different derivations I found floating around.
Yours is the only one that worked out of the box.
If you're happy to maintain this, it would be great to add a link to hls-nix from the haskell-language-server readme. Might prevent a few other people from waiting for GHC builds.

[alanz]

Would anyone like to update the README to reflect this?

[korayal]

@414owen I don't think my version is useful for everyone using nix, because the build is only confirmed on the fixed nixpkgs version I'm using on GHC 8.6.5. The nix expression could be useful for people trying this out on their own versions. I don't plan on maintaining this on any other combinations than what I use at the time. Even 'that' takes ~0-2 hours of my time depending on the change in dependencies.

It would be nice to build a hls clone for all-hies (or ghcide-nix) though. But unfortunately, I do not have the time to do that. but if someone does, I can support and contribute to that effort when I have the spare time.

[414owen]

@korayal fair enough. I might look into supporting more GHC versions and setting up CI.
Thanks for bootstrapping a build :)

[zypeh]

Is it ok if I work on this? I am learning Nix packaging and try to build hls on Nix too.

[korayal]

@414owen thanks! Btw, I did kick off a clone of ghcide-nix on a branch here for hls-nix and started a build for hls-ghc865. it could take hours, so I don't know if it will succeed on first try. but I think if we can make it build and push to a cache, it would be pretty easy to maintain. Maybe @domenkozar can help us out here.

@zypeh this can also be useful if you wanted to take on this challenge.

[domenkozar]

Would you be up to having Nix expressions in this repo? That would really make things easy.

[zypeh]

@domenkozar you mean having the nix expression installation working directly on this repo?

[domenkozar]

Yup.

[korayal]

My take above using ghcide-nix's haskell.nix method failed for this project, which I think is related to stack-to-nix, I got the error below:

substituteStream(): WARNING: pattern '# nix-sha256:' doesn't match anything in file 'stack-8.6.5.yaml'
fatal: not a tree object: fb3859dca2e54d1bbb2c873e68ed225fa179fbef
error: program 'git' failed with exit code 128
(use '--show-trace' to show detailed location information)

Which, I think is related to this dependency

edit: oh, it looks like stack-to-nix has a requirement to add the sha256 as comment.

[domenkozar]

That's right - it's quite tricky. As part of https://nix.dev/ I plan to write also a tutorial for haskell.nix

[korayal]

On my latest take I was able to build for GHC 8.8.3 and 8.6.5, but not others. GHC 8.10.1 is not supported by haskell.nix yet. I haven't digged deeper for 8.8.2 and 8.6.4.

On the other hand, since haskell-language-server exposes two executables (haskell-language-server and haskell-language-server-wrapper), when I install packages.haskell-language-server.components.exes, I get priority conflict on LICENCE files. But if I install packages.haskell-language-server.components.exes.haskell-language-server then change it's priority and then install packages.haskell-language-server.components.exes.haskell-language-server-wrapper, it does work. Though I don't think this is the way to fix that.

I've pushed to my cachix cache on that branch for both hls-ghc865 and hls-ghc883 for Linux.

unrelated to these above, but I was wondering about something. Right now this project is using ghcide as a submodule. Would it be possible to install this project without explicitly defining that ghcide dependency within nix files?

Normally when we install a nix package from GitHub we use the tarball and submodules are not included there.

[spacekitteh]

On my latest take I was able to build for GHC 8.8.3 and 8.6.5, but not others. GHC 8.10.1 is not supported by haskell.nix yet. I haven't digged deeper for 8.8.2 and 8.6.4.

On the other hand, since haskell-language-server exposes two executables (haskell-language-server and haskell-language-server-wrapper), when I install packages.haskell-language-server.components.exes, I get priority conflict on LICENCE files. But if I install packages.haskell-language-server.components.exes.haskell-language-server then change it's priority and then install packages.haskell-language-server.components.exes.haskell-language-server-wrapper, it does work. Though I don't think this is the way to fix that.

I've pushed to my cachix cache on that branch for both hls-ghc865 and hls-ghc883 for Linux.

Hmm. When I try installing hls-ghc883 using home-manager, I get a type error: The option value home.packages.[definition 23-entry 36]' in /home/spacekitteh/.config/nixpkgs/home.nix' is not of type package'.`

[spacekitteh]

Ah, your installation instructions were wrong. I'll submit a PR.

[korayal]

I just noticed there's already an issue on all-hies for this. I think the best path forward is to wait for/help @infinisil on that since he's already working on a haskell.nix port for all-hies.

[infinisil]

Here's the current issue for using haskell.nix for all-hies: infinisil/all-hies#19, with this branch having the changes: https://github.com/Infinisil/all-hies/tree/haskell.nix

It's a bit unfortunate that I can only get 8.6.5 and 8.8.3 working with it though :/

[poscat0x04]

I've just generated some nix derivations using the haskell.nix infra, they seem to be usable but I'm not entirely sure.

repo

Edit: The source links are incorrect, you'll need to clone haskell-language-server and point those links to the cloned folder.

[michaelpj]

I have a slightly different haskell.nix expression that I got working recently: https://github.com/input-output-hk/plutus/blob/6021baf728ed812a45a1a87c5deac2ee7d756d9d/nix/haskell-extra.nix#L33

[poscat0x04]

Did an overhaul to my repository, now it supports all GHC versions on both release version and the master version

[sir4ur0n]

Thank you @poscat0x04 , I have started again from your derivation and had it work on my project! I had to duplicate your project to change various things to make it work with my project though, so I opened a few issues on your repo to smoothen the derivation consumption, but it otherwise seems to work! I'd be happy to switch back to your derivation if you agree on these changes (and I can try to open PRs to do the changes I proposed).

Again, thank you!

[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 😉 ?

[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.