Hey, co-author of the Nix formatting RFC here, I want to expand with some info:
The RFC defines an entirely new standard for how to format Nix, it doesn’t pick an existing style, and differs completely from the original nixfmt style
The prototype for that RFCs formatting is merely _based_on the codebase of nixfmt, mainly because it was best suited architecturally
Since very recently, the RFC’s formatting is exposed as a Nixpkgs attribute pkgs.nixfmt-rfc-style on unstable channels. So it’s now very easy to install and try out
The RFC is very close to FCP and is going to make its formatting both official and enforced for Nixpkgs, so we expect that it become the community default. Minor changes to the formatting are still happening, and there are still bugs, but it’s very close.
It is worth noting, that despite the lack of fancy marketing, nixfmt also fulfills a lot of the properties alejandra claims:
“uncompromising”, i.e., it pretty-prints the AST from scratch
opinionated (mostly mine and Infinisil’s if you go with the RFC branch ^^ )
correct: nixfmt has the --verify flag which checks its output for idempotency and correct parsing. We fuzz it against the extensive test suite and the entirety of nixpkgs. We plan on adding CI that will actually use nix tooling to check that the output parses the same against the official cppnix parser. (While this is not a formal proof of correctness[^1], Alejandra doesn’t have one either)
At this point, I think that among the “uncompromising”/pretty-printing formatters, nixfmt-rfc-style is the most polished one currently and I’d recommend using it[^2]. Among the rules-based formatters, there is only nixpkgs-fmt but I think it generally is worth a look too.
[^1]: This got me thinking though, there probably would be a way to create an engine which formally proves correctness through the type system. However currently it would be a bit useless, since we lack a formal specification of the Nix grammar and semantics to prove against.
[^2]: Or forking it to make it match your own opinions. The nixfmt engine is the most maintainable and malleable of the code bases we tried, that’s also why we use it as basis for our RFC.
I wanted to update the article with your input too (if you allow so), but since you also suggest nixfmt-rfc-style is the most polished formatter currently having near feature-parity with alejandra, could we maybe also hope to get an opinion from @kamadorueda ?
The plan was to do some non-Nixpkgs repositories first. There are some segments of Nixpkgs being re-formatted by maintainers. They should add those commits to nixpkgs/.git-blame-ignore-revs at 36134ff4010203894314216675326404fbead273 · NixOS/nixpkgs · GitHub as they do so. Eventually there will be a mass re-format to get the remaining portions of Nixpkgs. Whether it is one large one or piecemeal depends on the situation at the moment.