# Enforcing Nix formatting in Nixpkgs
**URL:** https://discourse.nixos.org/t/enforcing-nix-formatting-in-nixpkgs/49506
**Category:** Development
**Created:** [July 23, 2024, 7:03pm UTC](https://discourse.nixos.org/t/enforcing-nix-formatting-in-nixpkgs/49506 "2024-07-23T19:03:19Z")
**Posts on this page:** 12
**Page:** 1
### Author:  [@Infinisil](https://discourse.nixos.org/u/Infinisil)
#### Post date: [July 23, 2024, 7:03pm UTC](https://discourse.nixos.org/t/enforcing-nix-formatting-in-nixpkgs/49506/1 "2024-07-23T19:03:19Z")
The [Nix formatting team](https://nixos.org/community/teams/formatting/) is happy to announce the next big step towards the implementation of accepted [RFC 166](https://github.com/NixOS/rfcs/pull/166): Enforcing the [official formatter](https://github.com/NixOS/nixfmt) on Nixpkgs!
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](https://github.com/NixOS/nixpkgs/blob/3178439a4e764da70ca83f47bc144a2a276b2f0b/shell.nix). This is enforced [using CI](https://github.com/NixOS/nixpkgs/blob/3178439a4e764da70ca83f47bc144a2a276b2f0b/.github/workflows/check-nix-format.yml) on all PRs.
If you notice any problems, please inform the Formatting Team (e.g. in the [Matrix room](https://matrix.to/#/#nix-formatting:nixos.org)) about workflow disruptions it causes. In case of emergency/security, PRs failing the formatting check can also be merged, it won’t break master.
Let’s go! 🚀
Edit: We also plan to do a [treewide Nixpkgs reformatting](https://github.com/NixOS/nixpkgs/pull/322537) soon, stay tuned!
---
### Author:  [@ppenguin](https://discourse.nixos.org/u/ppenguin)
#### Post date: [July 23, 2024, 9:09pm UTC](https://discourse.nixos.org/t/enforcing-nix-formatting-in-nixpkgs/49506/2 "2024-07-23T21:09:30Z")
Thanks for your efforts on standardisation!
As a coincidence, I had just stumbled on [this (ancient) topic](https://discourse.nixos.org/t/the-uncompromising-nix-code-formatter/17385), 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.
---
### Author:  [@Infinisil](https://discourse.nixos.org/u/Infinisil)
#### Post date: [July 23, 2024, 10:26pm UTC](https://discourse.nixos.org/t/enforcing-nix-formatting-in-nixpkgs/49506/3 "2024-07-23T22:26:32Z")
- Aug 2021: [RFC 101](https://github.com/NixOS/rfcs/pull/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](https://github.com/NixOS/rfcs/pull/101#issuecomment-1239601764) 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](https://github.com/NixOS/rfcs/pull/101#issuecomment-1402796012) bi-weekly shepherd meetings, there’s constant progress since then.
- Mar 2023: The shepherds are [using](https://github.com/NixOS/rfcs/pull/101#issuecomment-1586976949) the nixfmt codebase to try out the formatting style in practice, because it’s the easiest to adjust.
- Sep 2023: The shepherds [decide](https://github.com/NixOS/rfcs/pull/101#issuecomment-1716565416) to close RFC 101 in favor of opening a new one. Serokell also [agreed](https://github.com/NixOS/nixfmt/issues/129#issuecomment-1727534142) to transfer ownership of nixfmt to the NixOS GitHub org.
- Nov 2023: The shepherds open the new [RFC 166](https://github.com/NixOS/rfcs/pull/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](https://github.com/NixOS/rfcs/pull/166#issuecomment-1955268600), subsequently accepted after addressing the final feedback. The implementation of the RFC is [being started](https://github.com/NixOS/nixfmt/issues/153#issue-2182857136).
This took longer to write than I wanted it to take, but it’s an interesting history 😄
---
### Author:  [@mindtree](https://discourse.nixos.org/u/mindtree)
#### Post date: [July 24, 2024, 2:01am UTC](https://discourse.nixos.org/t/enforcing-nix-formatting-in-nixpkgs/49506/4 "2024-07-24T02:01:58Z")
So excited for this!
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!
---
### Author:  [@payas](https://discourse.nixos.org/u/payas)
#### Post date: [July 24, 2024, 4:30am UTC](https://discourse.nixos.org/t/enforcing-nix-formatting-in-nixpkgs/49506/5 "2024-07-24T04:30:09Z")
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?
---
### Author:  [@polygon](https://discourse.nixos.org/u/polygon)
#### Post date: [July 24, 2024, 12:16pm UTC](https://discourse.nixos.org/t/enforcing-nix-formatting-in-nixpkgs/49506/6 "2024-07-24T12:16:49Z")
> [@mindtree](#):
>
> Being able to just run a standard formatter and entirely skip those conversations is going to be a huge boon for contributors 😌
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.
---
### Author:  [@nicolas-goudry](https://discourse.nixos.org/u/nicolas-goudry)
#### Post date: [July 25, 2024, 12:53pm UTC](https://discourse.nixos.org/t/enforcing-nix-formatting-in-nixpkgs/49506/7 "2024-07-25T12:53:56Z")
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)?
---
### Author:  [@Infinisil](https://discourse.nixos.org/u/Infinisil)
#### Post date: [July 25, 2024, 2:54pm UTC](https://discourse.nixos.org/t/enforcing-nix-formatting-in-nixpkgs/49506/8 "2024-07-25T14:54:31Z")
> [@payas](#):
>
> On another note, does this mean we can finally rename `nixfmt-rfc-style` back to `nixfmt`?
I’d say let’s wait a bit longer with that, but yeah that’s the plan eventually 🙂
> [@payas](#):
>
> 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?
It’s in the [RFC 166 implementation tracking issue](https://github.com/NixOS/nixfmt/issues/153), 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 😉
> [@nicolas-goudry](#):
>
> 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)?
There’s still at least [Maintain expanded attrs/lists/attr params/inherits by infinisil · Pull Request #224 · NixOS/nixfmt · GitHub](https://github.com/NixOS/nixfmt/pull/224) to merge, perhaps also [/\* comments \*/ should not be reformatted · Issue #179 · NixOS/nixfmt · GitHub](https://github.com/NixOS/nixfmt/issues/179) before we go ahead with the [treewide reformat](https://github.com/NixOS/nixpkgs/pull/322537). But after that I think we can do a 1.0 release and call it stable (which notably wouldn’t mean that the formatting can’t change anymore!).
---
### Author:  [@Infinisil](https://discourse.nixos.org/u/Infinisil)
#### Post date: [July 25, 2024, 10:03pm UTC](https://discourse.nixos.org/t/enforcing-nix-formatting-in-nixpkgs/49506/9 "2024-07-25T22:03:27Z")
> [@nicolas-goudry](#):
>
> What will happen to nixpkgs-fmt then? Will it still be maintained?
Looks like no: [RIP nixpkgs-fmt · nix-community/nixpkgs-fmt@bdb15b4 · GitHub](https://github.com/nix-community/nixpkgs-fmt/commit/bdb15b4c7e0cb49ae091dd43113d0a938afae02c) 🪦
In any case, thank you, @zimbatm and contributors, for [nixpkgs-fmt](https://github.com/nix-community/nixpkgs-fmt) 🙇♂️! Even if its code doesn’t live on, some of its design decisions have made it into the [formatting standard](https://github.com/NixOS/nixfmt/blob/e819b2d0f9173f0c73d2e1fb4bc5155362046653/standard.md), such as the preservation of empty lines.
Similarly, thank you @kamadorueda and contributors for [alejandra](https://github.com/kamadorueda/alejandra) 🙇♂️! Notably alejandra is still being maintained and has [its own style that some users prefer](https://github.com/kamadorueda/alejandra/issues/404). 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](https://serokell.io/)!
---
### Author:  [@zimbatm](https://discourse.nixos.org/u/zimbatm)
#### Post date: [July 26, 2024, 7:51am UTC](https://discourse.nixos.org/t/enforcing-nix-formatting-in-nixpkgs/49506/10 "2024-07-26T07:51:11Z")
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 🙂
---
### Author:  [@nicolas-goudry](https://discourse.nixos.org/u/nicolas-goudry)
#### Post date: [July 30, 2024, 6:38pm UTC](https://discourse.nixos.org/t/enforcing-nix-formatting-in-nixpkgs/49506/11 "2024-07-30T18:38:14Z")
Sorry for the late reply! Thanks for the pointers and explanation about the versioning 🙂
> [@Infinisil](#):
>
> which notably wouldn’t mean that the formatting can’t change anymore!
I get it, but if the formatting changes, the version will too, right? At least that’s what I would expect as a user.
> [@Infinisil](#):
>
> Looks like no: [RIP nixpkgs-fmt · nix-community/nixpkgs-fmt@bdb15b4 · GitHub](https://github.com/nix-community/nixpkgs-fmt/commit/bdb15b4c7e0cb49ae091dd43113d0a938afae02c) 🪦
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!
---
### Author:  [@Infinisil](https://discourse.nixos.org/u/Infinisil)
#### Post date: [July 30, 2024, 9:27pm UTC](https://discourse.nixos.org/t/enforcing-nix-formatting-in-nixpkgs/49506/12 "2024-07-30T21:27:42Z")
> [@nicolas-goudry](#):
>
> I get it, but if the formatting changes, the version will too, right? At least that’s what I would expect as a user.
For now we’re still in the slightly unstable phase, but this sounds like a good policy to establish starting at version 1.0 🙂