Which nix formatter to use?

General
1

I’m hoping to get this sorted early so that all of our nix files can be formatted the same. I’m a personal enjoyer of nixfmt-rfc-style. However I’m aware that other options exist like alejandra. Just wanting to get some feedback before we finalize with a poll

8 Likes
2

Just posting some relevant links,
nixfmt-rfc-style is where upstream is going towards,

While some people including myself prefers alejandra

3 Likes
3

to me, it seems that alejandra produce less intended expression

2 Likes
4

I’d also suggest nixfmt-rfc-style. This reduces friction (merge conflicts) when pulling/pushing from/to nixpkgs.

4 Likes
5

I’d like to mention that adding treefmt-nix to the flake would simplify things for those who use other formatters.

1 Like
6

I think I hate all nix formatters, but not as much as I hate no-formatter.

I’m personally in favor of whatever is more like python-black. E.g. not Lisp or pep8 style. I think the multiline function body being on the same intent as the function arg is crazy, but it seems commonplace.

I’ve worked on my own formatter but its far from useful/done.

4 Likes
7

I’d just like to add sonething w.r.t alejandra: I’m personally uncomfortable with the advertising system that was put in place with v3.0.0. I’d feel bad pushing software that shows an ad every time it’s run, especially when it seems to be controlled by a single person.

I get why people like it though, its formatting is still my preferred one. But I’m more in favor of nixfmt-rfc-style.

5 Likes
8

We’ve been using nixfmt-rfc-style on the templates repo.
The ci over there makes sure you’ve formatted your code with that and that you’re passing statix lints.

Personally, I’m in favor of this setup. :raised_hand:

6 Likes
9

I am going to shill @getchoo’s nix flake checks GitHub - getchoo/flake-checks: ✅ Simple, lightweight, and reusable Nix flake checks, I’ve been really enjoying them. Though they are more for CI format checking.

5 Likes
10

As one of the authors of the formatting RFC I am of course strongly biased in favor of nixfmt-rfc-style.

I think that it is important to distinguish the format produced by a formatter from its code base. If you actually want to deploy a formatter at scale, then things like correctness, polish, and maintainability are at least as important as the format itself. And to the extent I tried out all of them, only the nixfmt code base is up to the task.

If you disagree with the current style produced by nixfmt, you’d have an easier time adapting nixfmt to your preferred style than trying to get Alejandra up to speed. (Ask me how I know.) However, I’d ask you to reconsider if going down that rabbit whole once again is worth it, since we have already built consensus on this style through an RFC.

12 Likes
11

I don’t have a strong opinion on formatter, but +1 for combining statix
From my personal experience, it has mostly helped reduce repeated keys in attribute sets.
For example,

 85 │       focus-ring.enable = true;
    ·       ────────┬────────  
    ·               ╰────────── The key focus-ring is first assigned here ...
 86 │       focus-ring.active.color = "rgb(245 194 231)";
    ·       ───────────┬───────────  
    ·                  ╰───────────── ... repeated here ...
 87 │       focus-ring.inactive.color = "rgb(24 24 37)";
    ·       ────────────┬────────────  
    ·                   ╰────────────── ... and here. Try focus-ring = { enable=...; active.color=...; inactive.color=...; } instead.
6 Likes
12

I was going to chime in to say I like alejandra but yikes!

I think I’ll be migrating soon.

13

I think I’ve seen a patch for that… If I find it ill share.

1 Like
14

I don’t care what formatting style we use. What I care about is having aux fmt built in and standard to the CLI and used in all official aux codebases.

5 Likes
15

Goes without saying, but I’d love aux lint built in too :smile:

edit: auxolintl pls :smile:

6 Likes
16

nixos/nixfmt is the obvious choice here imo. the community at large has already had much discussion in this in the original rfc; i don’t see a point in rehashing that here

statix is really great along with deadnix. i would like to keep these projects separate though as they are far from aux exclusive, and would probably lead to duplicate work if they were to be upstreamed

4 Likes
17

nixfmt-rfc-style is the obvious choice imo.

2 Likes
18

Wow ads in a formatter thats new

To be fair, I nice little one line git patch on that FOSS repo would probably fix that right up. That or a CLI wrapper

2 Likes
19

Oh right I did mention I would come back when I found the patch. Well I found it nyxpkgs/pkgs/tools/nix/alejandra-no-ads/0001-no-ads.patch at main · NotAShelf/nyxpkgs · GitHub

3 Likes
20

I’m with everyone suggesting to use nixfmt-rfc-style, I think using one formatter per language is better than everyone coming up with their own formatting styles.

2 Likes