We’ve never deprecated a platform in widespread use before, and it
seems prudent to warn users about the upcoming end of support so they
can plan appropriately.
I tried to make this relatively unobtrusive by taking advantage of
the import cache and offering a way to turn it off, but I anticipate
there might still be issues with e.g. `nix shell nixpkgs#…` and
spammy warnings from multiple instantiations of Nixpkgs. I’m
not sure there’s much we can do about that unless we take a
different strategy entirely; `nix shell --impure nixpkgs#…` with a
`~/.config/nixpkgs/config.nix` is about the best UX we can hope to
offer with the restrictions of flakes.
After final improvements to the official formatter implementation,
this commit now performs the first treewide reformat of Nix files using it.
This is part of the implementation of RFC 166.
Only "inactive" files are reformatted, meaning only files that
aren't being touched by any PR with activity in the past 2 months.
This is to avoid conflicts for PRs that might soon be merged.
Later we can do a full treewide reformat to get the rest,
which should not cause as many conflicts.
A CI check has already been running for some time to ensure that new and
already-formatted files are formatted, so the files being reformatted here
should also stay formatted.
This commit was automatically created and can be verified using
nix-build a08b3a4d19.tar.gz \
--argstr baseRev b32a094368
result/bin/apply-formatting $NIXPKGS_PATH
With nix 2.4 the fact that we set NIX_STATE_DIR, but kept the original
store became a hard error. We work around it here by forcing the use of
a fresh, sandbox-local, store.
See regnat's wonderful analysis for more information:
https://github.com/NixOS/nix/issues/5495#issuecomment-963949707
This allows the aliases file to produce deprecation warnings
without triggering the check against warnings. This allows
for a better user experience when deprecations occur.
Moreover, Nixpkgs itself shouldn't rely on its backcompat aliases.
