Nix build is unstable; Should we keep it?

[Anton-Latukha]

Recently master & so all PRs started to:
https://github.com/haskell/haskell-language-server/runs/4509561080?check_suite_focus=true

> nix build --print-build-logs
...
ghcide> Setup: Encountered missing or private dependencies:
ghcide> hie-bios >=0.8 && <0.9.0
...
error: 1 dependencies of derivation '/nix/store/ckcngbdahcmykc05rljj0cpkqvjicslb-haskell-language-server-1.5.1.0.drv' failed to build
Error: Process completed with exit code 1.

[jneira]

ouch, the nix build seems to be fragile lately, do we know if some pr broke it? maybe we should trigger the nix build in all prs and not only in master?

//cc @maralorn @michaelpj

[Anton-Latukha]

Yep, it is: https://github.com/haskell/haskell-language-server/pull/2470/files it raised the hie-bios bound to 0.8 & Nixpkgs current & that is now pinned use 0.7.1.

Nixpkgs (especially sure of haskellPackages) has a different versioning solving system (no versioning solving system) than Cabal & Stack, that is why these can't be avoided.

The downside is - putting checks to the PRs would now suddenly put on the unaware Haskell code writing devs a sudden requirement of Nix code maintenance. & some part of Nix loving Haskell devs should already use Nix dev env - so those PRs then should already be Nix-aware. & people which do not know Nix - would not be able to solve Nix things without maintainer support.

& then the solution starts from that position. As I see it - both variants under evaluation are the same value but with different side effects. Which is decided - is not for me to decide.

[michaelpj]

Well, or it could run on changes that touch cabal files only.

Honestly, I'm not convinced that the nix build as it stands is fit for purpose. HLS is a fast-moving project that frequently uses bleeding-edge versions of libraries that have just been released to Hackage. The nixpkgs Haskell setup is based on infrequently updated Hackage snapshots, and is more suited for building stable software.

As it is, to fix things like this would require some tedious patching in of the new versions of libraries every time someone tries to use a newly released library. Not a good UX for contributors.

(I don't even use the fancy Nix setup to work on HLS! I just work in a nix-shell with ghc and cabal and it's fine.)

[Anton-Latukha]

I agree that for HLS it is challenging to maintain Nix dev env. I agree that Nix code does not suite the bleeding-edge development, especially as close & as fast to the core ecosystem as HLS should. It basically would/requires constant repinings & overloading of the packages.

Nix is good for deployments of releases & for the use of projects locally. But development in it - means keeping to the Nixpkgs/flake versions & need to overload & then remove or reoverload everything additional. It is not that frequent for most projects, but still. I'd wished Nix packaging had the ability to have bound constraints mode for development purposes - that would've solved all this almost fully.

I did not create & I not maintained the Nix setup - so not me to decide about it.

Seems a simple straw pool can shine some data on this situation.

[jneira]

The downside is - putting checks to the PRs would now suddenly put on the unaware Haskell code writing devs a sudden requirement of Nix code maintenance. & some part of Nix loving Haskell devs should already use Nix dev env - so those PRs then should already be Nix-aware. & people which do not know Nix - would not be able to solve Nix things without maintainer support.

totally agree

[pepeiborra]

Honestly, I'm not convinced that the nix build as it stands is fit for purpose. HLS is a fast-moving project that frequently uses bleeding-edge versions of libraries that have just been released to Hackage. The nixpkgs Haskell setup is based on infrequently updated Hackage snapshots, and is more suited for building stable software.

Completely agreed. The previous shell.nix descriptor was designed with this in mind, I think the upgrade to Flakes has proven to be a step in the wrong direction.

[michaelpj]

cc @berberman

[Ailrun]

Will be fixed with this commit: a6b5b32

[berberman]

nix build here is another distribution method, independent from cabal-install and stack, which means we have to duplicate the changes of the build config to nix.

Imagine that we want to update a dependency of ghcide, which was just released to Hackage. For cabal-install, the only thing we need to do is to update the package index. For stack, we need to add this new package to extra-deps of each stack descriptor. For nix build, first we need to distribute this new package to nix, and then put it into Haskell package set.

Given that the update frequency of Haskell packages in nixpkgs is not as fast as it used to be, the leaving maintenance cost is indeed high for us, and nix is totally optional for Haskell developers, so I have no objection to no longer ensure the build status of nix build.