So over the last years, it constantly bothered me that expressions in my nix files were never sorted enough to my liking even after using the available formatters like nixfmt; examples would be module arguments ({lib, config ...} vs {config, lib, ...}) but also the attribute sets themselves. Since nix does not work line-by-line, it makes in my mind not a lot of sense to apply custom ordering to attributes rather than a uniform one (except for maybe let and rec).
For the last one or so weeks, I was working on a solution to this “problem”, which I coined “the pedantic Nix formatter”, or pedantix in short. It builds on top of your base formatter of choice (and stays in compliance with it) and is basically fully customizable to your liking. It ensures a fully uniform structure between all of your nix files
After migrating my own config to it without any issues arising, I decided today that this marks the first stable release. Also, I threw it against nixpkgs to see how the future could look like when using pedantix you can find that result here. Nixpkgs still fully evaluated after that, so I guess it is safe for you to trust it with your own config
I thought this might be useful for other people as well, so here you go!
Yeah, inconsistent argument ordering is quite annoying! I had the idea to write ast-grep rules to order arguments, but I might have to try this just for that.
Also,
merging of repeated keys (this does not fix broken evaluations)
Been waiting for this fix to land in Statix for a while.
This actually looks like something id want. I appreciate not hardcoding the formatring style. I do prefer how alejandra does things over nixfmt personally.
Though, before i start relying on it, I do have to ask for LLM use disclosure. Have any LLMs been used during this projects development?
Yes I used AI as assistance when coding this; if this is a killer for you I can understand (a while ago it maybe would have been for me as well), however I can assure you that I created this with as much care as I could give.
It is also rather easy to evaluate whether the tool works correctly, and at the moment I am very sure that it does^^
Yes I used AI as assistance when coding this; if this is a killer for you I can understand
Yeah sadly i’ll have to pass on this then.
It is also rather easy to evaluate whether the tool works correctly, and at the moment I am very sure that it does^^
Indeed, though for me that was never a question in the first place.
EDIT: please disclose LLM use next time, it’s something some folks (me for example) really care about. Disclosure will help avoid this exchange, which in the end was pointless. Good luck with the project
Following the policy that has been stated here, I do not believe that I have to put such a disclaimer in my opening post. If my stance is disagreeable, feel free to delete this thread.
If anyone wants to talk about the actual, tool, I am very happy to do so
I can see this being particularly useful in the nixpkgs CI, as it could finally help us reach a consistent agreement on how attributes should be organized within a derivation. We regularly spend time debating this during PR reviews, and this project could definitely help resolve that.
To make adoption easier, integration with treefmt-nix would be really useful.
Yeah I also had this in the back of my mind and I would also love to see a solution to this; however I seem to remember reading content ordering was deliberately not done during adoption of nixfmt? I just found this Enforce certain attribute ordering in packages · Issue #428 · NixOS/nixfmt · GitHub , maybe this is just a nixfmt stance and not a nixpkgs one.
You are talking about upstream integration right? treefmt support itself is already provided by pedantix
IMO, I wish we could have one single tool that does everything, and does it well… but it’s not the case yet. Perhaps it will change one day ? I don’t know.
I added an explicit LICENSE now, I only had it set in the nix package.
Fair point, I had not thought about excluding directories in pedantix itself, rather than manage this directly through treefmt. As for different presets per directory, you can place a config file in each directory (or one of its parents, for that matter) that should use a different preset (and/or config in general), which will then again be picked up by treefmt. In the nixpkgs PoC above (treewide: format using pedantix · Swarsel/nixpkgs@4aa6836 · GitHub) this is done to apply the module and package presets on the respective directories - but I guess that commit is not the easiest to overview
One use case where actual per-file (not just per-directory) presets would definitely help is @mightyiam’s .pkg.nix pattern for callPackage in dendritic configs:
The dendritic pattern is merely a pattern. It’s not a religion, law or a mandate. Use it where it fits and make exceptions where appropriate. Having Nixpkgs callPackage files interspersed among top-level module files is one reasonable exception to the pattern. Of course, they’d have to be excluded from automatic importing. A suggested naming scheme for these: my-package.pkg.nix.
It would be useful to be able to have those follow the callPackage preset when everything else in that directory is formatted as a flake-parts module.
you can find that result here. Nixpkgs still fully evaluated after that, so I guess it is safe for you to trust it with your own config 
