Update the Nix build #5796
Update the Nix build #5796
Conversation
On macOS, it requires access to `security`, which is outside the sandbox, so don’t sandbox it when running on Darwin. This is made possible by setting `sandbox` to `relaxed` in the flake, which allows using `__noChroot` to mark derivations as unsandboxed. This makes things less strict on Linux (where the sandbox is on by default), but more strict on Darwin (where the sandbox is off by default).
This allows us to install a different version than the one included in Nixpkgs (although we don’t currently do that). It also makes some syntactic changes to other tools for consistency.
This reduces the closure size a bit, and puts us on a consistent Nixpkgs version. This forces an upgrade of Stack from 2.15.7 to 3.5.1, and correspondingly an upgrade of hpack from 0.35.2 to 0.38.0.
Updating Nixpkgs resulted in a pile of “GHC 9.6.5 is out of date” warnings, so this brings us to the end of the 9.6 line. GHC is managed by the Stack resolver, so we can upgrade to GHC 9.8.4 or 9.10.2 without modifying the flake.
This ensures we’re using the versions in Nixpkgs. - cabal 3.10.3.0 → 3.14.2.0 - haskell-language-server 2.8.0.0 → 2.10.0.0
This ensures we’re using the version in Nixpkgs. It also reformats everything. - ormolu 0.7.2.0 → 0.7.4.0
This workaround required another local workaround. If you had a line like `LD_LIBRARY_PATH=` in your .envrc, it can be removed now.
It is not triggering a(nother) rebuild of GHC.
Somewhat described at https://github.com/nix-systems/nix-systems This is useful for Haskell projects, because commands like ```bash nix flake show --allow-import-from-derivation ``` can often fail, complaining that it can’t find some other architecture to build on. With nix-systems, you can append `--override-input systems github:nix-systems/x86_64-linux` to the command to ensure that x86_64-linux is the only platform in play. This also adds aarch64-linux to the matrix, since that is one of the “default” systems in flake-utils.
|
From the Nix side this looks reasonable to me, but I vaguely remember there being some discussions in the past about specific Stack versions and what we should be on. I think that the main thing is just to keep people on roughly the same Stack versions? Anyway @aryairani, @mitchellwrosen, and @dolio (whom I don't think cares about the Stack version but probably does GHC) should probably be the ones to weigh in on that. |
Right. I think nix/versions.nix (which imports .vscode/settings.json) is the current best effort for that. That file could use a bit more documentation, but it’s
IMO, places that set versions outside of nix/versions.nix3 are bugs to be fixed. E.g., we could templatize files that mention versions (e.g., GitHub workflows, .vscode/settings.json, check-formatting), and regenerate them during some part of the build. That said, I’m happy to get pushback on the specific versions (some are easier to convince Nix to change than others) and on the overall method for keeping versions in sync. Footnotes
|
|
This derivation builds fine for me, but when I try to No amount of deleting stack files seems to help with this. |
We had conditionally enabled it on Linux, but it just made the builds inconsistent.
This brings everything Nix-related up to date.1
It also shrinks the closure size (mostly by eliminating a number of Nixpkgs inputs), adopts the nix-systems pattern to
allow downstream control over the included systems, and makes a number of other minor changes.
Footnotes
The GHC update also affects all Stack builds and the Cabal, HLS, and Stack updates also affect VS Code users. ↩