Specifically, all new files, and changed files that were already formatted, must now be formatted using nixfmt, which is available as a pinned version in the nix-shell of Nixpkgs. This is enforced using CI on all PRs.
If you notice any problems, please inform the Formatting Team (e.g. in the Matrix room) about workflow disruptions it causes. In case of emergency/security, PRs failing the formatting check can also be merged, it won’t break master.
As a coincidence, I had just stumbled on this (ancient) topic, which was suddenly on my radar since a trivial PR to nixpkgs of mine “blew up” on auto-formatting all-packages.nix (with alejandra, the discovery of which was a coincidence due to it being a default in nvf (nix-wrapper-config-module for nvim.)
What I was a bit surprised about was that the mentioned formatter seemed to have huge interest/momentum at the time (in 2022), I believe mostly in tandem with RFC101, but that I couldn’t easily find historical info on the decision making process after that, that apparently eventually lead to RFC166 “overruling” the former, getting us where we are now.
Don’t get me wrong, I think the fact that there is an official consensus now trumps any other considerations, I’m just interested in the decision making process that lead us here.
Aug 2021: RFC 101 was opened, essentially saying “let’s just use nixpkgs-fmt”, the alternatives of the original nixfmt and alejandra were also brought up, but not much progress was happening
Jul 2022: The shepherds (which are changing throughout) agree to decide on a formatting style independently of the formatter, but it stalled again after that.
Jan 2023: I take over as shepherd lead, and start leading bi-weekly shepherd meetings, there’s constant progress since then.
Mar 2023: The shepherds are using the nixfmt codebase to try out the formatting style in practice, because it’s the easiest to adjust.
Sep 2023: The shepherds decide to close RFC 101 in favor of opening a new one. Serokell also agreed to transfer ownership of nixfmt to the NixOS GitHub org.
Nov 2023: The shepherds open the new RFC 166 as the rework of the original RFC, nominating and being accepted as shepherds again
Feb 2024: After addressing all the feedback in the new RFC, the shepherds call for FCP, subsequently accepted after addressing the final feedback. The implementation of the RFC is being started.
This took longer to write than I wanted it to take, but it’s an interesting history
50%+ of the feedback (and delay) I get on my PRs to nixpkgs is some minor white-space nit or formatting personal opinion that the randomly selected maintainer happens to have, often differing from other maintainers, and impossible to predict before submitting the PR.
Being able to just run a standard formatter and entirely skip those conversations is going to be a huge boon for contributors
Thanks for all your effort in picking and landing one as a standard!
Great work @Infinisil! Sheer perseverence has been amazing to witness.
On another note, does this mean we can finally rename nixfmt-rfc-style back to nixfmt?
I also remember some mention of integrating the chosen formatter within Nix itself, so as to not need a separate tool apart from nix format. Is that still the plan?
So much this. It’s not important that each developer likes every part of the standard style. It’s way more important that there is a blessed default style and a formatter that automatically applies it to code.
That’s a huge great news! Thanks for all this work
Not so long ago I was wondering if I should switch from nixpkgs-fmt to alejandra and when I searched for an official consensus I couldn’t find a clearly defined one.
What will happen to nixpkgs-fmt then? Will it still be maintained?
Also, I noticed in the nixfmt repository that it states the following:
The official (but not yet stable) formatter for Nix code
Should it still be considered unstable? Should we expect a v1 release soon (last one is from October 2023)?
I’d say let’s wait a bit longer with that, but yeah that’s the plan eventually
It’s in the RFC 166 implementation tracking issue, so yeah. I likely won’t get to that anytime soon, but anybody else is free to do that, just synchronise with the formatting team
In any case, thank you, @zimbatm and contributors, for nixpkgs-fmt! Even if its code doesn’t live on, some of its design decisions have made it into the formatting standard, such as the preservation of empty lines.
Similarly, thank you @kamadorueda and contributors for alejandra! Notably alejandra is still being maintained and has its own style that some users prefer. Also here, some of its design decisions made it into the formatting standard, such as the trailing-comma style for attribute arguments.
Ultimately we started with three formatter code bases and had to pick one of them. I’m glad we were able to reuse the original nixfmt codebase, thanks for donating that, Serokell!
Thanks to @Rizary and @matklad, who were instrumental in creating nixpkgs-fmt.
Now that there is an official formatter, I think unifying the styles is more valuable than going with my personal taste. It was a lot of fun diving into this world. I learned a lot of things. And I’m looking forward to never having a conversation around formatting again
Sorry for the late reply! Thanks for the pointers and explanation about the versioning
I get it, but if the formatting changes, the version will too, right? At least that’s what I would expect as a user.
Oh, right, I don’t know how I missed that! I even did visit the repo before posting Thanks for letting me know! I’ll start using nixfmt from now on then!
! Even if its code doesn’t live on, some of its design decisions have made it into the 
Thanks for letting me know! I’ll start using nixfmt from now on then!