Nix support for GHC upgrade #5155
Conversation
This `only-tools-nixpkgs` devShell generally paralleled the `cabal-only-tools` devShell, but avoiding haskell.nix. While I’m not a huge fan of haskell.nix, this just created duplication and gave us a shell with a somewhat different environment than the one used by `nix build`, etc. It also didn’t work for everyone. In removing that shell, it also sets the default devShell to be `cabal-only-tools`, which some people were already using to work around issues with the previous default.
There are various benefits to using a Nixpkgs release - more likely that things are cached - easier to update the input without breaking everything This also renames a lot of things in the flake: - `nixpkgs-unstable` to `nixpkgs-release` – partially because it’s not unstable any more, but also because both it and the nixpkgs from haskell.nix unstable, so it didn’t really clarify anything - `nixpkgs` to `nixpkgs-haskellNix` – to make it clear where it comes from - `unstable` to `release-pkgs` – the convention is to use `pkgs` for derivation attrsets, and the source switched from unstable to release - `nixpkgs-packages` to `tool-pkgs` – this holds our build tools, so that seemed clearer than “nixpkgs”
Overlays are for derivations, and this isn’t one. Putting it in an overlay also just gives us more levels of indirection to dig through to figure out where things are coming from.
`cabal-local` no longer triggers rebuilds of GHC, so now we can use the devShell that provides the same environment as our build.
This means those environments will also be cached in CI.
Bumped some versions around, but they’re negotiable. - ormolu 0.5.2.0 → 0.7.2.0 - hls 2.9.0.0 → 2.8.0.0 - stack 2.15.5 → 2.15.7
|
Most of the commits here are part of #5154, which simplifies the flake on trunk. This PR consists of just a single commit. Also, there is one test that fails under @ceedubs has a workaround for this in https://github.com/ceedubs/unison-nix/blob/trunk/nix/darwin-security-hack.nix, but I also think it’s not critical for now, since we don’t run |
|
If we change the ormolu version in nix, we should change it in CI also. And then I don't know how to get non-nix users to match; the vs code haskell plugin pulls down some version of ormolu (embedded in some version of HLS), but I don't even know how to find out what version it is. |
Yeah, this is one of the use cases for pulling the versions out into a JSON file1, then read that into the flake, workflows, etc.
Yeah, my inclination is to use the ones here unless @ChrisPenner has a strong preference, only because it reduces the overrides needed by Nix and less Nix code is better Nix code. Footnotes
|
|
The “Nix development cache / ubuntu-20.04” check is failing because it runs out of space trying to build GHC 9.6.5 😕 I should try building that locally and pushing it to the cache. |
|
Given @ChrisPenner’s comment, I think the only question is whether it’s ok to bump Ormolu here. If so, does that mean this PR also needs to run it across the code base? |
|
If ormolu has a lot of changes then I'd really love to NOT do that right now, as it'll cause a ton of merge conflicts with my project root stuff 😓 ; if it's not too bad maybe it's fine? |
Bumped some versions around, but they’re negotiable.