Reduce the Nix setup in this repository

[michaelpj]

The current Nix setup is approximately always broken. This isn't surprising, since we tend to rely on lots of packages that have just been released, which is hard for the current Nix setup to support.

The only thing that I think we can offer if we're not able to build all the dependencies is a simple shell with a compiler and dev tools. And I think that's fine - personally I already only use the "simple" dev shell, because it's the only one that reliably works.

So I propose cutting it down to just the simple dev shells.

cc some people who might care @guibou @cydparser @Gabriella439

[guibou]

I'm using the nix setup to deploy HLS at work, but I'm ok with a huge simplification, the rest can be moved to another repo.

[michaelpj]

Yeah, I don't think we really want to commit to supporting a setup for deploying a bleeding-edge HLS. For most users the one in nixpkgs is hopefully adequate, and anyone else has to do something else.

[cab404]

Let's at least add patchelf-d executables?
This way you won't be needing to mess with builds, and Nix users will still be able to depend on hls in their flakes.

[michaelpj]

If you want to add it and you commit to maintaining it and keeping it working then maybe. Ultimately I just don't think the HLS team is interested in providing distribution via the flake. If people were using it that way then I think that was mostly an accident. nixpkgs distributes a nix build of HLS, or you can do it yourself using haskell.nix or whatever.

[cab404]

If you want to add it and you commit to maintaining it and keeping it working then maybe. Ultimately I just don't think the HLS team is interested in providing distribution via the flake. If people were using it that way then I think that was mostly an accident. nixpkgs distributes a nix build of HLS, or you can do it yourself using haskell.nix or whatever.

I am suggesting it for the sole reason it's not as complicated as maintaining the behemoth that nixpkgs haskell packaging is. I am honestly surprised that someone have time and mental strength to maintain it at all, actually.

It will just download existing binaries from releases, and patch in nixpkgs shared libraries.

[sir4ur0n]

I think providing an hermetic Nix shell is quite valuable, and I would be sad if HLS removed support for it.

Typically when I started working on #3771, all I had to do was nix develop .\#haskell-language-server-94-dev-nix and Everything Just Worked ™️
The friction from "Hey, what if I contributed to HLS?" to "Ok let's hack" was very low.

With the basic Nix shell (nix develop), I now have to:

• modify the global state of Cabal on my machine (cabal update)
• install globally some libraries (e.g. zlib)
• etc.

I don't think I would have even started working on #3771 if the dev-nix shell was not provided.

I am not a frequent HLS contributor though, so my opinion is not as valuable as frequent HLS contributors, and I understand maintaining infrastructure you don't use can be frustrating, too.

I just wanted to voice my concern 😅

Now if HLS were to keep such infrastructure, I would advise (if not already done) to have CI use those dev shells and build HLS in it, and block merging if CI fails. E.g. IMO #3796 should not have been merged until the Nix dev shells were fixed, too

[fendor]

Now if HLS were to keep such infrastructure, I would advise (if not already done) to have CI use those dev shells and build HLS in it, and block merging if CI fails.

The issue with this is nix CI often breaks without being changed. And it breaks while stack and cabal builds succeed.
Sometimes, you need to manually jailbreak version constraints, or add recently released dependencies.
Having three sources of truth for building a project is a recipe for disaster, which is why we decided to remove that blocker.
Even worse, the nix CI often breaks for completely unrelated reasons and is impossible to fix for non-nix users.

Therefore, I am very much against making nix CI mandatory, unless someone commits to maintenance, helping out other users.

[michaelpj]

I think Fendor summed it up well. I think more specifically, the current Nix setup is based on the nixpkgs Haskell infrastructure, and as such you need to add stuff to it whenever you want to use a package version that is not in nixpkgs. We are very often on the bleeding edge of newly released packages, so this is... all the time. It's terrible, and we cannot expect most (or even any except a few experts) to maintain this.

What might be acceptable (and I might investigate this later) is a haskell.nix-based shell, since that pretty much Just Works off a cabal.project. It does still require some steps to update occasionally, so it might still be too annoying. Not sure.

With the basic Nix shell (nix develop), I now have to:

Running cabal update does not seem so bad. I think having to install global stuff is just a bug in the shell, which we should fix. Apart from that I don't see the problem with it. It's the one I've been using (since the other one is always broken), and I find it just fine. The main annoyance is that the dependencies aren't cached, but otherwise it works pretty well (on NixOS).