Nix installation?
spacekitteh opened this issue · comments
Anyone have a nix expression to install this?
@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.
Would anyone like to update the README to reflect this?
@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.
@korayal fair enough. I might look into supporting more GHC versions and setting up CI.
Thanks for bootstrapping a build :)
Is it ok if I work on this? I am learning Nix packaging and try to build hls on Nix too.
@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.
Would you be up to having Nix expressions in this repo? That would really make things easy.
@domenkozar you mean having the nix expression installation working directly on this repo?
Yup.
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.
That's right - it's quite tricky. As part of https://nix.dev/ I plan to write also a tutorial for haskell.nix
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.
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-serverandhaskell-language-server-wrapper), when I install packages.haskell-language-server.components.exes, I get priority conflict onLICENCEfiles. But if I installpackages.haskell-language-server.components.exes.haskell-language-serverthen change it's priority and then installpackages.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-ghc865andhls-ghc883for 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'.`
Ah, your installation instructions were wrong. I'll submit a PR.
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.
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 :/
I've just generated some nix derivations using the haskell.nix infra, they seem to be usable but I'm not entirely sure.
Edit: The source links are incorrect, you'll need to clone haskell-language-server and point those links to the cloned folder.
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
Did an overhaul to my repository, now it supports all GHC versions on both release version and the master version
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!
Anybody have an up-to-date version for the vanilla Haskell infrastructure?
For what it's worth: a first version has been merged into the nixpkgs repository 2 days ago, thanks to @GuillaumeDesforges, see NixOS/nixpkgs#91279 for more information.
I don't think it's yet available on nixpkgs-unstable channel, but it should land soon.
Oh sweet!
Hmm, what attribute is it under?
@GuillaumeDesforges are you able to tell us more? I just tested with nixpkgs-unstable and I can't find the haskell-language-server executable, nor hls, neither at top level or inside haskellPackages, but I'm not 100% familiar with how Haskell packages are updated/published on nixpkgs.
You can find nixpkgs status here:
https://status.nixos.org/
It says that the last update was yesterday for nixpkgs-unstable, so it should be there after updating the channel (are you on the unstable channel?)
It should be available in (import <nixpkgs> {}).haskell.packages.ghc883.haskell-language-server
EDIT: just checked
nix-repl> (import <nixpkgs> {}).lib.version
"20.09pre233323.dc80d7bc4a2"
nix-repl> (import <nixpkgs> {}).haskell.packages.ghc883.haskell-language-server
«derivation /nix/store/ia0slqaljc6jyvpphc79y49ra4ir3b5k-haskell-language-server-0.1.0.0.drv»
[arsleust@poseideep:~]$ nix-shell -p haskell.packages.ghc883.haskell-language-server
[nix-shell:~]$ haskell-language-server --version
ghcide version: 0.1.0.0 (GHC: 8.8.3) (PATH: /nix/store/da1s18qqbgqn0aj1v5sbh2vrqbbs1z2c-haskell-language-server-0.1.0.0/bin/haskell-language-server)
You can then create a Haskell dev environment as usual using the nixpkgs Haskell infrastructure. Someone should probably work on adding it to haskell.nix.
Thank you Guillaume, I think I am more lost because of Nix then 🤔
$ nix-channel --list
nixpkgs https://nixos.org/channels/nixpkgs-unstable
$ nix-channel --update
unpacking channels...
$ echo $NIX_PATH
/home/sir4ur0n/.nix-defexpr/channels:/home/sir4ur0n/.nix-defexpr/channels
$ ll /home/sir4ur0n/.nix-defexpr/channels/
nixpkgs -> /nix/store/fazhhnw3ywcxxh16zlbb15h381gvxc2f-nixpkgs-20.09pre233103.4855aa62fa1/nixpkgs/
$ nix repl
nix-repl> (import <nixpkgs> {}).lib.version
"20.09pre233103.4855aa62fa1"
nix-repl> (import <nixpkgs> {}).haskell.packages.ghc883.haskell-language-server
error: attribute 'haskell-language-server' missing, at (string):1:1I assume based on the number 233103 that my version is older than yours 233323 (which may explain why I don't yet see the HLS package), however for the life of me I can't figure out what I'm doing wrong 😐
If anyone would be kind enough to tell me what's wrong, I would appreciate 🙇 I did search on Nix documentation but could not find any other way than nix-channel --update to update my nixpkgs...
I found I had to run nix-channel --update twice for it to actually work for some reason 🤷♀️
I found I had to run
nix-channel --updatetwice for it to actually work for some reason 🤷♀️
What. The. F*ck.
I just tested and it also worked O_o
Would anybody be able to explain this dark magic/bug?
Slightly unrelated question: how come the packages doesn't appear in https://nixos.org/nixos/packages.html?channel=nixpkgs-unstable&query=haskell-language-server ?
Slightly unrelated question: how come the packages doesn't appear in https://nixos.org/nixos/packages.html?channel=nixpkgs-unstable&query=haskell-language-server ?
I just clicked on your linked btw, please check that you are looking at unstable channel
Yes, I am, it's part of the URL...
When I click:
Interestingly, when trying in a private-mode browser, it appears:
I guess this is related to caching, however this website is highly confusing, as it displays a loading bar (even on my regular web browser) before displaying "No results found", so the user (at least me) expects this is a server response, not some cache:
Note: it still displays "No results found" when force refreshing (in Chrome: Ctrl + F5, Shift + F5)...
I guess this solves this mystery, though I find it a poor user experience :/
If anyone is affiliated or knows maintainers of this website, this may be worth letting them know 😞
In case anyone is interested, I took a second look at this caching problem.
The problem seems to come from the fact that this page at some points loads https://channels.nixos.org/nixpkgs-unstable/packages.json.br which is a HTTP 301 (redirect to the latest nixpkgs).
On my regular browser, it hits a disk cache and thus always targets https://releases.nixos.org/nixpkgs/nixpkgs-20.09pre232864.55668eb671b/packages.json.br (even if using Ctrl + F5)
Note the version is stuck at 232864.
When doing the same thing in an incognito browser, it redirects to https://releases.nixos.org/nixpkgs/nixpkgs-20.09pre233849.1d801806827/packages.json.br (note the version is 233849).
The former does not contain haskell-language-server, the latter does.
I guess the page should not cache this 301 redirect 🤷♂️
Short experience report. Moved project to nixos-unstable-small rev 9ab83c6eed9d1c6840940f5918713383346706a3 and GHC 8.8.4. Had to add haskell.packages.ghc884.haskell-language-server to my shell.nix. This gives:
haskell-language-server version: 0.2.2.0 (GHC: 8.8.4) (...)
And... it's alive! VS code plugin picked it up automatically.
@GuillaumeDesforges nice work! 👍
Thank you @GuillaumeDesforges!!
It's worth noting that the version pointed to by nixpkgs doesn't have PR #243, which fixed an issue with lsp-haskell in emacs (see here). In case anyone else runs into that: I got around it by modifying the HLS nixpkgs derivation to point at master, which wouldn't compile because nixpkgs doesn't have lsp-test 0.11.0.3 yet, so I forked HLS to remove that dependency (that fork here), and turned off the check phase.
Since currently cachix cache does not have enough pre build versions. I create a simple python3 script to ease the installation of all pre-builds binaries from github release.
Besides documenting the availability in Nixpkgs (with a minimal shell.nix example?), is there anything else to be done in this issue? If not, I can try to open a PR and then we finally close this issue?
Hi, I was able to get it to work with haskell.nix, see here: https://github.com/hasktorch/hasktorch-skeleton/blob/master/nix/default.nix#L35-L54 and here: https://github.com/hasktorch/hasktorch-skeleton/blob/master/shell.nix#L24
Can someone help me install the 864 version with nix, using fetchUrl? I tried this, but I can't make it work.
{ pkgs ? import ../nixpkgs.nix }:
pkgs.stdenv.mkDerivation rec {
name = "haskell-language-server";
src = pkgs.fetchurl {
url = "https://github.com/haskell/haskell-language-server/releases/download/0.3.0/haskell-language-server-Linux-8.6.4.gz";
sha256 = "1q3vq2gdb3zsmxab1fmq4s7f7p4r3kdzn709aqf83hhfx18sn1rj";
};
phases = ["installPhase"];
installPhase = ''
mkdir -p $out/bin
${pkgs.gzip}/bin/gzip -d $src $out/bin
chmod +x $out/bin/haskell-language-server-Linux-8.6.4
'';
}
@peterstorm I'd advice using the haskell-language-server from nixpkgs:
for instance if you want a shell.nix file for nix-shell:
{ pkgs ? import <nixpkgs> }:
pkgs.mkShell {
buildInputs = with pkgs; [ cabal-install stack haskell.packages.ghc864.haskell-language-server ];
}your <nixpkgs> should be "unstable" (see https://nixos.wiki/wiki/Nix_channels)
Oh, I didn't know that version was added, I'll check that out, thank you @GuillaumeDesforges!
@GuillaumeDesforges
Hmm, it says that the gh864 attribute is missing, and I'm importing sources from unstable :(
Oops, ghc864 not gh864
Well, seems like ghc864 has been dropped in favor of ghc865. Can you upgrade?
@GuillaumeDesforges Not really, I'm on that specific version because of a GHCJS project :( I'll try to figure out how to get the binary
This issue is fixed and can be closed. The latest version is in Nixpkgs; it can be installed just like any other Haskell package.
@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'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 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
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
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.
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?
Is there a way to have a
haskell-language-server-wrapperexecutable that can work out what version of GHC the project uses, and runs it's respectivehaskell-language-serverexecutable on Nix?
I was just on my way to signal that NixOS/nixpkgs#99519 has been merged, so wrapped hls will soon land on nixpkgs unstable.
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! 😄
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.
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 :)
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.
FYI: I've seen ghcide/HLS segfault on Nix when using TH https://github.com/haskell/ghcide/issues/910
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 😀
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.
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.
@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.
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.
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 ?
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
@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.
@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
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.
@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.
@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.
@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.
@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?
@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.
@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.
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)?
@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.
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.
@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).
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 linkingglibc).
I would fully support a PR that did this
@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 ofglibc.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 linkingglibc).
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
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 😉 ?
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.
wow, wonderful, thanks for the info, will link it in our docs
#2256 will close this epic issue, very much thanks to you all
To add a late addition: HLS is pretty easily buildable with haskell.nix, by pointing it at the HLS repository and using cabalProject.
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.