We need Nixpkgs linting

Development
1

The amount of person-hours we currently waste on manually reviewing things which could be automated is not okay. The advantages of automated code quality checking:

  • It reduces the amount of back and forth between author and reviewer, because a lot of fixes can be done locally already. This reduces stress and is faster due to having a lower round trip latency.
  • It reduces the amount of nitpicky review comments, increasing the signal-to-noise ratio for actually important review comments.
  • Higher quality pull requests, which allows reviews to directly focus on the important parts, which is more efficient.
  • Having a guaranteed minimum code quality would give us more trust in distributing merge rights to more people, as discussed in More granular commit access control via merge bot

I already dedicated a lot of time last year onto getting Nixpkgs auto-formatted for this exact reason, but the other half of the equation is to have a good and powerful linter.

I think that a linter for Nixpkgs should meet the following requirements:

  • Being able to run locally, with fast iteration times
  • Provide good error messages and feedback about what should be done
  • A powerful architecture that allows to express various kinds of rules. Static analysis is a must, evaluation-based linting would be a welcome addition
  • Commit message linting
  • Easily extensible; People should be able to add new lints for things that come up frequently
  • Granular configuration, especially for the transition phase
  • Tooling integration, e.g. with GitHub warnings or IDE extensions

There are already projects who tackle this problem, so we won’t start at zero. What we currently need is a group of people who dedicate themselves to that goal and actively push things forward. An RFC might be a good tool for that, or a working group.

28 Likes
2

cc @Artturin and @siraben because you maintain GitHub - nix-community/nixpkgs-lint: A fast semantic linter for Nix using tree-sitter 🌳 + ❄️. [maintainers=@Artturin,@siraben]

1 Like
3

and @jtojnar, who maintains GitHub - jtojnar/nixpkgs-hammering: Beat your package expressions into a shape.

1 Like
4

and @astro came into my mind, because of GitHub - astro/deadnix: Scan Nix files for dead code

5

cc @flokli @sternenseemann who works on tvix and possess linting capabilities built-in the evaluator.

1 Like
6

cc @nerdypepper who maintains GitHub - nerdypepper/statix: lints and suggestions for the nix programming language. it’s a great tool that i’ve been using for a while that can also catch some less obvious anti-practices like eta-reduction

7

FWIW, deadnix has a library API: deadnix - Rust

nil can do even more: GitHub - oxalica/nil: NIx Language server, an incremental analysis assistant for writing in Nix.

1 Like
8

Does this come with automatically revoking commit access for non-derivation-changing review comments without a reference to a linter issue (possibly freshly open)? Because most cheap linting will end up being about non-derivation-changing things that also don’t change logical structure, and if it is only about readability for very pro-uniformity people, it’s useless for the others without enforcing structure on the complaints (nitpicky complaints are the real problem)…

1 Like