Nix flake fix dev shells

[guibou]

This is a work in progress.

This clean and fixs the nix develop shells for GHC 9.2 and GHC 9.0.

See individual commits for details, but in summary:

• nix develop .#haskell-language-server-ghc921-dev now works.
• When entering the shell, it creates an alias for cabal which points to the correct cabal-xxx.project

I'm planning on testing on GHC 9.0 soon too (but right now it is building the world of dependencies).

Future commits to this MR will (hopefully) includes:

• Support for GHC 9.0
• I'd like to restore the CI steps related to nix/flake, as an optionnal step which can be triggered on demand by developers. It will also populate the cachix cache.
• Additional cleanups. I'm trying to remove all the explicit "hacks" if version == ...

[michaelpj]

When entering the shell, it creates an alias for cabal which points to the correct cabal-xxx.project

I'm a little wary of this. It's nice if you know it's there, but it's hidden magic and adds a source of confusion ("I can't cabal build with 9.0", "I can".... "oh, one of us was using the magic cabal wrapper").

[guibou]

When entering the shell, it creates an alias for cabal which points to the correct cabal-xxx.project

I'm a little wary of this. It's nice if you know it's there, but it's hidden magic and adds a source of confusion ("I can't cabal build with 9.0", "I can".... "oh, one of us was using the magic cabal wrapper").

I agree.

What about if the alias is called cabal_ghc92, so you must explicitly use cabal_ghc92 build, and a message is printed when entering the shell, such as:

Cabal won't be able to build your project without using the project file `cabal-xxx.project`. An alias `cabal_ghcxxx` was automatically created for you and uses this cabal project. Use it like:

cabal_ghcxxx build

[michaelpj]

That sounds fine to me, although at that point I might as well type --project-file=... myself :) The warning is nice though!

[guibou]

A few changes:

• As suggested by @michaelpj, the alias when entering the nix-shell is not cabal, but cabal_project. A message warns the user about the need to use a special cabal.project file, as well about the existence of the alias.

• I simplified the shell. Previously, it was trying to build the haskell dependencies using nix. However, this was problematic because:

  • Once in the shell, cabal build may decide to use different version, and hence was rebuilding. So we were building dependencies twices.
  • Theses dependencies may fail to build, and the nix-shell may not start.
  • It clutters the nix setup, because we had to detect the Haskell dependencies used by hls, and manually remove the broken plugins. The new approach is simpler, it just starts a shell with ghc, cabal and a few C dependencies (zlib, ...).

[michaelpj]

Personally, I'm in favour of what you do here, just having the dev shell contain the system dependencies and letting cabal build the rest. In fact, that's what I do already (I don't use the existing dev shells for that reason!). However, possibly some people (@berberman ?) like the way it's done currently.

[jneira]

the nix build in master is failing since https://github.com/haskell/haskell-language-server/actions/runs/1778521865 (the merge of #2668):

error: builder for '/nix/store/5hz103hms77w33chs4170kws3h5mxp63-haskell-language-server-1.6.1.0.drv' failed with exit code 1;
       last 10 log lines:
       > post-installation fixup
       > shrinking RPATHs of ELF executables and libraries in /nix/store/y2m3d2c0a1wa1j0p7skgvfvzm9sqnh5d-haskell-language-server-1.6.1.0
       > shrinking /nix/store/y2m3d2c0a1wa1j0p7skgvfvzm9sqnh5d-haskell-language-server-1.6.1.0/bin/haskell-language-server-wrapper
       > shrinking /nix/store/y2m3d2c0a1wa1j0p7skgvfvzm9sqnh5d-haskell-language-server-1.6.1.0/bin/haskell-language-server
       > shrinking /nix/store/y2m3d2c0a1wa1j0p7skgvfvzm9sqnh5d-haskell-language-server-1.6.1.0/lib/ghc-8.10.7/x86_64-linux-ghc-8.10.7/libHShaskell-language-server-1.6.1.0-KvnnT3SgOLdLTY2wE4rDC1-ghc8.10.7.so
       > strip is /nix/store/xiq6j4jsyj351p8q3yw9cg1hdqp9m685-gcc-wrapper-10.3.0/bin/strip
       > stripping (with command strip and flags -S) in /nix/store/y2m3d2c0a1wa1j0p7skgvfvzm9sqnh5d-haskell-language-server-1.6.1.0/lib  /nix/store/y2m3d2c0a1wa1j0p7skgvfvzm9sqnh5d-haskell-language-server-1.6.1.0/bin
       > patching script interpreter paths in /nix/store/y2m3d2c0a1wa1j0p7skgvfvzm9sqnh5d-haskell-language-server-1.6.1.0
       > checking for references to /build/ in /nix/store/y2m3d2c0a1wa1j0p7skgvfvzm9sqnh5d-haskell-language-server-1.6.1.0...
       > RPATH of binary /nix/store/y2m3d2c0a1wa1j0p7skgvfvzm9sqnh5d-haskell-language-server-1.6.1.0/bin/haskell-language-server contains a forbidden reference to /build/
       For full logs, run 'nix log /nix/store/5hz103hms77w33chs4170kws3h5mxp63-haskell-language-server-1.6.1.0.drv'.
Error: Process completed with exit code 1.

[guibou]

I've pushed a change with both type of shell (i.e. simple deps where cabal builds the dependencies, or complete deps).

I've also changed the CI so it builds HLS and shells for all flavors of them, effectively populating cachix for them.

[guibou]

the nix build in master is failing since https://github.com/haskell/haskell-language-server/actions/runs/1778521865 (the merge of #2668):

error: builder for '/nix/store/5hz103hms77w33chs4170kws3h5mxp63-haskell-language-server-1.6.1.0.drv' failed with exit code 1;
       last 10 log lines:
       > post-installation fixup
       > shrinking RPATHs of ELF executables and libraries in /nix/store/y2m3d2c0a1wa1j0p7skgvfvzm9sqnh5d-haskell-language-server-1.6.1.0
       > shrinking /nix/store/y2m3d2c0a1wa1j0p7skgvfvzm9sqnh5d-haskell-language-server-1.6.1.0/bin/haskell-language-server-wrapper
       > shrinking /nix/store/y2m3d2c0a1wa1j0p7skgvfvzm9sqnh5d-haskell-language-server-1.6.1.0/bin/haskell-language-server
       > shrinking /nix/store/y2m3d2c0a1wa1j0p7skgvfvzm9sqnh5d-haskell-language-server-1.6.1.0/lib/ghc-8.10.7/x86_64-linux-ghc-8.10.7/libHShaskell-language-server-1.6.1.0-KvnnT3SgOLdLTY2wE4rDC1-ghc8.10.7.so
       > strip is /nix/store/xiq6j4jsyj351p8q3yw9cg1hdqp9m685-gcc-wrapper-10.3.0/bin/strip
       > stripping (with command strip and flags -S) in /nix/store/y2m3d2c0a1wa1j0p7skgvfvzm9sqnh5d-haskell-language-server-1.6.1.0/lib  /nix/store/y2m3d2c0a1wa1j0p7skgvfvzm9sqnh5d-haskell-language-server-1.6.1.0/bin
       > patching script interpreter paths in /nix/store/y2m3d2c0a1wa1j0p7skgvfvzm9sqnh5d-haskell-language-server-1.6.1.0
       > checking for references to /build/ in /nix/store/y2m3d2c0a1wa1j0p7skgvfvzm9sqnh5d-haskell-language-server-1.6.1.0...
       > RPATH of binary /nix/store/y2m3d2c0a1wa1j0p7skgvfvzm9sqnh5d-haskell-language-server-1.6.1.0/bin/haskell-language-server contains a forbidden reference to /build/
       For full logs, run 'nix log /nix/store/5hz103hms77w33chs4170kws3h5mxp63-haskell-language-server-1.6.1.0.drv'.
Error: Process completed with exit code 1.

Yes:

       > RPATH of binary /nix/store/y2m3d2c0a1wa1j0p7skgvfvzm9sqnh5d-haskell-language-server-1.6.1.0/bin/haskell-language-server contains a forbidden reference to /build/

I'm having a look.

[guibou]

@jneira the build is now fixed, but now that HLS is not statically linked anymore, it does have the nix ghc package as a dependency, which bumps the uncompressed closure size to 6 GiB.

I initially thought that it should not be an issue, because people are actually using HLS to develop with GHC, so chances are that they also pull ghc in their dev environment. However, due to how nix flake works, they may use a different nixpkgs clone, and hence use a different ghc.

[guibou]

Developement shell for macos for GHC 8.8.4 is failing.

I have no idea how to fix that, I'll disable it.

[guibou]

I've disable nix dev shell building for all but the current GHC version. (i.e. that's strictly more than what was previously tested). Let's see if it passes test like that, then we'll merge and later I'll try to fix it.

[guibou]

I don't understand the latest failing job. Could we merge with that?

[michaelpj]

LGTM!

[michaelpj]

Now trying to actually use this:

> nix develop .#haskell-language-server-ghc921-dev 

error: flake 'git+file:///home/michael/projects/forks/haskell-language-server' does not provide attribute 'devShells.x86_64-linux.haskell-language-server-ghc921-dev', 'packages.x86_64-linux.haskell-language-server-ghc921-dev', 'legacyPackages.x86_64-linux.haskell-language-server-ghc921-dev' or 'haskell-language-server-ghc921-dev'

> nix develop
> cabal build ghcide

session-loader/Development/IDE/Session/VersionCheck.hs:17:24: error:
    • Exception when trying to run compile-time code:
        I could not find a GHC installation at /nix/store/2dgrlf17sdjg3vjgs637xbj8kfmd3yxw-ghc-8.10.7/lib/ghc-8.10.7. Please do a clean rebuild and/or reinstall GHC.
CallStack (from HasCallStack):
  error, called at src/GHC/Check.hs:188:7 in ghc-check-0.5.0.6-29a80c8b99e2ee9e01c4d3d0858431da25b86b57be8c1c611f95e6a5d1788945:GHC.Check
      Code: makeGhcVersionChecker
              (fromMaybe GHC.Paths.libdir <$> lookupEnv "NIX_GHC_LIBDIR")
    • In the Template Haskell splice
        $$(makeGhcVersionChecker
             (fromMaybe GHC.Paths.libdir <$> lookupEnv "NIX_GHC_LIBDIR"))
      In the expression:
        $$(makeGhcVersionChecker
             (fromMaybe GHC.Paths.libdir <$> lookupEnv "NIX_GHC_LIBDIR"))
      In an equation for ‘ghcVersionChecker’:
          ghcVersionChecker
            = $$(makeGhcVersionChecker
                   (fromMaybe GHC.Paths.libdir <$> lookupEnv "NIX_GHC_LIBDIR"))

🤷

[michaelpj]

Setting NIX_GHC_LIBDIR helped me with the second one.

[guibou]

I'm sorry.

I tried your second example and it works fine for me. Have you tried cabal clean first? But first, could you grep -R 2dgrlf17sdjg3vjgs637xbj8kfmd3yxw-ghc-8.10.7 *. I'm suspecting that there is an hidden / leftover state somewhere. For one reason, I do not have /nix/store/2dgrlf17sdjg3vjgs637xbj8kfmd3yxw-ghc-8.10.7 on my machine, so you have a reference to something that my invocation of nix-shell or nix-develop did not pulled.

For the first one

nix develop .#haskell-language-server-ghc921-dev 

I can indeed reproduce the problem ;( However it works for me with nix develop .\#haskell-language-server-921-dev (see the missing ghc in my invocation). Is that just an error from your side, or did you read this line from a documentation / example / something and that there is something to fix?

[michaelpj]

No need to apologize, just reporting!

I'm suspecting that there is an hidden / leftover state somewhere.

Yes, I suspect you may be right. cabal clean didn't fix it, but I suspect the path may actually have crept into one of the packages in the cabal store...

Is that just an error from your side, or did you read this line from a documentation / example / something and that there is something to fix?

Aha, that does it! I just blindly copied it out of the PR description because I was trying to figure out how to trigger one of the other shells. I should have checked more closely! It does indeed work with the right attribute name 🤦

[guibou]

Aha, that does it! I just blindly copied it out of the PR description because I was trying to figure out how to trigger one of the other shells. I should have checked more closely! It does indeed work with the right attribute name facepalm

I use auto completion (with zsh or bash) to get the available entry points. nix flake show is also supposed to do that, but I had never been able to get it to work.