Simplifying Nix

[sellout]

Overview

This makes a number of changes – they make much more sense if you review commit-by-commit. Here are the highlights:

• with Direnv, use flake should hopefully work for all users, now – no need to specify cabal-only-tools to get a working environment
• a lot of extra packages have been trimmed from the outputs
• the dual haskell.nix / non-haskell.nix environments have gone away, making it much easier to keep things in sync
• CI should now cache our packages correctly
• there is now ~100 fewer lines of Nix code, which is 29% of the Nix in this repo (and I think there is more that can be removed)

This is some preliminary work to support #5142.

Interesting/controversial decisions

It’s Nix – it’s all controversial.

Loose ends

nix flake show still wants to build GHC 8.10.7 for some reason, but nothing else seems to trigger that issue.

[sellout]

@ceedubs @mitchellwrosen – just to annoy you two, this PR removes cabal-only-tools, but on the plus side, bare use flake should work for you again.

Also, if anyone wants to try this out before it’s merged that’d be awesome.

[neduard]

Hey @sellout this is awesome! I was wondering if the flake could be simplified. I'm using NixOS so let me quickly give it a spin (will edit comment once I've done so)

[sellout]

But I was under the impression that a lot of the complexity was due to supporting specific GHC/ormolu/etc versions that didn't necessarily line up with what was in nixpkgs/haskell.nix. Do you know? As long as @aryairani, @mitchellwrosen, and @ChrisPenner are good with the versions being used, then I think we are good.

This does maintain the same versions of everything as before. One of the reasons for the multiple devShells previously was issues with the IOG cache that resulted in GHC having to be rebuilt by devs. That is fixed for the use cases we generally support. I think that keeping the versions in sync between the two devShells was then a source of complication. The removal of the second devShell is reflected in c16337508d5cbbc86b9583f5629bbac9837347cf and 07c7ca437127ccc703a7a7291950145352f17808, where you can see is where we got most of the code removal from. It does look like GHC got unpinned, but the version of GHC used by the haskell.nix devShell comes from stack.yaml – it only needed to be included in the flake to ensure that the non-haskell.nix version also matched.

There are some real changes here, though. E.g., haskell-language-server no longer disables its various plugins. This way

1. we get an upstream cached version,
2. it’s more likely to match the configuration that non-Nix users have, and
3. it’s less Nix code.

I think that Nix can have good libraries with solid APIs, etc. but it’s not there yet and as a result things start looking complicated quite quickly. I.e., you really gotta justify every line of it.

And one benefit of a clear & documented (possibly literate?) flake is that it can also serve as a guide for non-Nix users to follow when setting up their own environment. So things like haskell.nix get hidden away, while version numbers, configuration options, supported platforms, etc. are presented up front.

[neduard]

Hmm I tried nix -L build '.#component-unison-cli:lib:unison-cli' locally and it seems to have built using ghc-9.2.8 (after compiling for a long time):

fd unison result/
result/lib/x86_64-linux-ghc-9.2.8/libHSunison-cli-0.0.0-9ZrQZ6gitIF8svWfJHSDe4-ghc9.2.8.so
result/lib/x86_64-linux-ghc-9.2.8/unison-cli-0.0.0-9ZrQZ6gitIF8svWfJHSDe4/
result/lib/x86_64-linux-ghc-9.2.8/unison-cli-0.0.0-9ZrQZ6gitIF8svWfJHSDe4/
...

Looking at CI it seems to also be pulling in ghc-9.2.8?

Any ideas on what might cause this?

[sellout]

Hmm I tried nix -L build '.#component-unison-cli:lib:unison-cli' locally and it seems to have built using ghc-9.2.8 (after compiling for a long time)

This is the expected version on trunk. GHC 9.6.5 support hasn’t been merged yet. For these same changes for that GHC, look at #5155.

As far as the long build – it didn’t rebuild GHC itself, right? 🤞🏼 (That was an issue we were having before) Soon our cache should have all of the latest hashes cached (after merging this, if not before).

[neduard]

it didn’t rebuild GHC itself, right?

I think it did given the time and since I recall (and I can't retest it now as https://ci.zw3rk.com is returning a 502), but it's okay; it sounds like a cache propagation issue. Thanks for clarifying regarding the ghc-version 👍

[aryairani]

this is part of #5142 now