Update nix flake

[ceedubs]

This still keeps nixpkgs on the 24.05 release, because 24.11 updates stack to version 3, which isn't currently being
used by ucm devs/CI. But it updates the dependencies in the flake.lock.

This does update hpack from 0.35.2 to 0.36.1. I think that this is probably fine, because I see checked-in files that
report that they were generated by hpack 0.36. But I also have no idea what I'm doing in the Haskell world.

[ceedubs]

I thought that this might trigger a recompiling of the Haskell world. And it seemed to on my machine. But it didn't seem to in CI and I'm not quite sure why that is. Is it that CI won't pick up my changes to the build?

[sellout]

I thought that this might trigger a recompiling of the Haskell world. And it seemed to on my machine. But it didn't seem to in CI and I'm not quite sure why that is. Is it that CI won't pick up my changes to the build?

@aryairani disabled Nix in CI, so it has to be triggered manually, which I did: https://github.com/unisonweb/unison/actions/runs/12127152567. Maybe Arya could comment on why, but it seems reasonable enough to just trigger a build when Nix stuff changes, which isn’t too often. (And it might be worth adding macos-14 to that matrix, now that that’s a supported platform).

As an aside, I’ve pinned releases in the cache (and should get the more recent ones up there), which makes it easier to check for when bugs were introduced, etc. if you’re a Nix user.

[sellout]

This makes me think we should bump HLS in .vscode/settings.json (which is also read by the flake) to 2.9.0.1. That’s the version @ChrisPenner had intended in the last update, but Nix wasn’t there yet.

Some other versions may also be bumpable, but slightly harder to discover.

I also noticed that while VS Code & Nix are using Stack 2.15.7, the GitHub workflows are using 2.15.5, so maybe worth bringing those in sync as well (would really like to get those workflows to read versions from a JSON file eventually …)

GHC 9.6.6 is out, too, but that means bumping the Stackage LTS, so maybe too much for this PR. I dunno.

[sellout]

I forgot that it’s not officially part of the PR checks, so to be clear, my approval is conditional on https://github.com/unisonweb/unison/actions/runs/12127152567 passing.

[ceedubs]

@sellout good call. That build failed. It may be the case that it would finish next time since it has succeeded in populating some of the cachix cache. But I don't know if that's something we want to depend on. Was this an issue before or were we getting more cache hits on the publich nix cache @aryairani?

[sellout]

Right … I forgot about that. Maybe that’s why Arya disabled it. This definitely happens.

When I was making Nix changes, I started pushing to the cache from my own machines first, since I was doing the builds anyway (at least for one arch). So, something like nix -L build --accept-flake-config --no-link --keep-going '.#all' | cachix push unison should do it, assuming you have auth to push to the cache. But if you don’t have an x86_64-linux (in this case), then it’s harder.

[sellout]

This should probably be captured in the Nix section of development.markdown … or, move all the Nix stuff into nix/README.md, and have development.markdown point there, rather than cluttering it for us handful of Nix users.

[sellout]

This reminded me of some changes I had never pushed, that I now have: #5486.

Since #5486 changes how we get the Stack version, upgrading to a newer Nixpkgs release shouldn’t be a problem (other than rebuilds).

[sellout]

Looks like there was a reason I hadn’t pushed that code … not working.

[sellout]

I got #5486 working, but as soon as you change an input, you might as well bump versions, because everything is getting rebuilt anyway. So, that may obviate this PR. What do you think about it @ceedubs?