unisonweb
Nix support for GHC upgrade
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 nix flake check:
clearWatchCache.CodebaseFormat2 EXCEPTION!!!: security: createProcess: posix_spawnp: does not exist (No such file or directory)
💥 clearWatchCache.CodebaseFormat2
@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 nix flake check in CI yet.
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.
also we should figure out between #5155 and #5142 which versions of hls and stack to standardize on too
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 file[^1], then read that into the flake, workflows, etc.
[^1]: Or probably YAML, so we can have comments like “this is set to match the version of Ormolu included in the VSCode Haskell plugin.”
also we should figure out between #5155 and #5142 which versions of hls and stack to standardize on too
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.
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?
