nixfmt-tree: refactor impl to use treefmt.withConfig

[MattSturgeon]

Follow up to #390147 and #384857, this PR refactors the new nixfmt-tree package to make use of the new treefmt.withConfig wrapper.

This is technically a breaking change:

1. Overriding settings will no longer entirely replace all settings, instead settings are now merged as modules.
2. Adding the package to a nix shell will no longer make runtime inputs (such as nixfmt) available on the PATH, only the wrapped treefmt will be added to the shell's PATH.

There are also non-breaking changes:

1. Introduced runtimeInputs, for consistency with treefmt.withConfig and other parts of nixpkgs, such as writeShellApplication.
2. Introduced nixfmtPackage to allow specifying a different nixfmt package, without having to know to override nixfmt-rfc-style.
3. Deprecated runtimePackages with a warning. Use the new args instead.

We could have it so that runtime inputs still end up being installed to $out/bin/, but this would negate much of the advantage of delegating most impl-details to treefmt.withConfig. In hindsight, it also feels like a bit of a leaky abstraction?

Fixes #395045

cc @infinisil @NixOS/nix-formatting

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:
  • package tests: nix-build -A nixfmt-tree.tests
• 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/)
• 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (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.

---

Add a 👍 reaction to pull requests you find important.

[infinisil]

LGTM!

[infinisil]

Yeah so this was the original motivation for including the formatter binaries as well, but as explained in the last formatting team meeting, people should be using treefmt even for format-on-save, because treefmt knows about the options you format the codebase with :)

[MattSturgeon]

Any objections to getting this merged @NixOS/nix-formatting ?

[jfly]

One thought for you inline. I trust your decision either way.

[MattSturgeon]

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 391319

---

x86_64-linux

✅ 1 package built:

• nixfmt-tree

[MattSturgeon]

Based on @jfly's feedback, I've reworked the runtimePackages -> runtimeInputs migrations a little:

I introduced a nixfmtPackage argument. This allows users to modify or replace the nixfmt package without having to explicitly override nixfmt-rfc-style. I'm open to alternative names or approaches here.

The (old) runtimePackages argument defaults to [ nixfmtPackage ] and the (new) runtimeInputs argument defaults to [ ].

The final runtimeInputs supplied to treefmt.withConfig is runtimePackages ++ runtimeInputs. Once runtimePackages is removed, that'll just be [ nixfmtPackage ] ++ runtimeInputs.

If a user explicitly overrides runtimePackages, they will see a deprecation warning:

nix-repl> pkgs.nixfmt-tree.override { runtimePackages = []; }
evaluation warning: nixfmt-tree: overriding `runtimePackages` is deprecated, use `runtimeInputs` instead.
                    Note: you do not need to supply a nixfmt package when using `runtimeInputs`, however you can override `nixfmtPackage` to a different nixfmt package.
                    For additional flexibility, or to configure treefmt without nixfmt, consider using `treefmt.withConfig` instead of `nixfmt-tree`.
«derivation /nix/store/l4xmpvzzwrmhxn3bmmicw0wpa2rh4ngh-nixfmt-tree.drv»

[jfly]

LGTM! I was surprised to see the binary name "nixmt" still hardcoded in this PR, rather than using lib.getExe, but IIUC, it has to be this way for backwards compatibility. I believe this can get cleaner in the future when we drop support for backwards compatiblity.

Thanks for iterating on this!

[MattSturgeon]

I was surprised to see the binary name "nixmt" still hardcoded in this PR, rather than using lib.getExe

Currently we're running nixfmt from the PATH; having added it to the PATH via runtimeInputs and makeWrapper.

Not adding nixfmt to the PATH and instead configuring its absolute path (via lib.getExe) is also an option. I think the migration for runtimePackages → runtimeInputs may be more work, or handle less edge-cases, but I'm open to trying it out if you prefer.

[jfly]

but I'm open to trying it out if you prefer.

No, let's merge this. We can revisit this in the future when we drop the deprecated codepath.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/formatting-team-meeting-2025-04-01/62524/1

[0xda157]

@MattSturgeon could this be backported to 24.11? EDIT: oops I meant #390147, but this would also be good. Also thinking about it more the branch off of 25.05 is in only a few days so it probably doesn't make sense to do a significant backport like this. Basically what I'm saying is ignore this.