nixfmt[-rfc-style]: unstable -> 1.0.0

[infinisil]

Updates Nixfmt to the stable release, see NixOS/nixfmt#316 and NixOS/nixfmt#272.

Cc @GaetanLepage ;)

Also:

• Updates the update script to use stable versions going forward
• Make pkgs.nixfmt the -rfc-style version and remove the warning
• Create a (delayed) warning for the -rfc-style version to encourage switching to pkgs.nixfmt in a couple releases

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• Nixpkgs 25.11 Release Notes (or backporting 25.05 Nixpkgs Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
• NixOS 25.11 Release Notes (or backporting 25.05 NixOS Release notes)
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other contributing documentation in corresponding paths.

---

This work is funded by Antithesis and Tweag ✨

Add a 👍 reaction to pull requests you find important.

[acid-bong]

yeah, i prefer yours 🌚

[emilazy]

We’ll need to do a (backported) treewide, right? Otherwise all these update scripts will produce results that break CI.

[infinisil]

Yeah, once we update the pinned CI tooling (once the result of this PR is built by Hydra), we'll need to reformat Nixpkgs again and backport that.

[MattSturgeon]

it directly affects how contributors to nixpkgs and the rest of the nix ecosystem will happen

Contributions to nixpkgs should be using treefmt from nixpkgs' dev shell, so in that regard it shouldn't matter what version of nixfmt is packaged in any particular channel.

I'm a bit worried about the effects of not having a formatter on stable that reflects the Nixpkgs formatting, not just for Nixpkgs but also for third-party projects with less elaborate pinning mechanisms in CI.

I agree, some consistency would be better.

I believe we usually backport updates to unstable software, so it makes sense to backport the update to nixfmt-rfc-style, so that the package is up to date.

But I'm still not convinced we should backport the rename. Switching which package the nixfmt attribute refers to feels like something that should only be done on unstable.

(I was mostly thinking about the rename in my last comment, not the package bump itself)

[wolfgangwalther]

I believe we usually backport updates to unstable software, so it makes sense to backport the update to nixfmt-rfc-style, so that the package is up to date.

But I'm still not convinced we should backport the rename. Switching which package the nixfmt attribute refers to feels like something that should only be done on unstable.

I'm mostly thinking about the package bump for the backport, so a selective backport of that would be fine by me.

Edit: Anyone on 25.05 using nixfmt-rfc-style has an expectation that the results of this match the results of the official formatter used in nixpkgs. Thus, we must update the package.

[wolfgangwalther]

Backport of only the version bump in #427082.