POC: automated linting of nixpkgs with rules files #427098
Conversation
|
I did some experiments with ast-grep as well, while refactoring You already mentioned that ast-grep can parse other code, too. Most importantly, it's possible to set up language injections, for example for bash code. There is a very limited example for some special cases here: technowledgy/refactor-tractor@200fc18. This means, it would be possible to lint the bash code inside nix expressions, too.
Having linting rules live in files inside the nixpkgs repo is certainly a big plus, I think. On the flip side, I think this would probably not be able to replace any of the existing tools: Certainly not treefmt / nixfmt. But also not Personally, I think ast-grep's biggest value is in the ability to do ad-hoc stuff. To experiment. To codify treewides. To do migrations from one pattern to another. That being said, I could still imagine something where we add another ast-grep job to CI. This would allow people to experiment and codify certain rules. Imho, the goal should then be to move those rules to Although I already see one example in this PR of a rule, that I would not like to have in nixpkgs-vet / any other repo: Everything that refers to specific attributes in nixpkgs and keeps a list of those, should stay in-tree forever. Otherwise, we're moving into what |
|
Makes sense. What you say about using ast-grep as a tree-wide rewrite tool also resonates with me. With some more documenataion I can see how this could be used more widely. |
|
Yeah, I think a framework for how to use this quickly and efficiently in nixpkgs, and some nixpkgs-specific documentation would help big-time. So many treewides are written with simple sed replacements, where ast-grep would be so much better. |
Motivation
In this POC I'm exploring how we could convert linting rules from documentation to code.
There is prior art such as nixpkgs-vet, nixpkgs-hammer, etc... The difference here is that the rules would live in rule files, sitting in nixpkgs. By having them here, it makes it easy to understand, discuss and evolve them alongside the code.
ast-grep is a tool that allows doing just that for any language that can be parsed with tree-sitter. That means we can also use it to set rules for accompanying Bash and Python scripts. Another nice thing is the support for auto-fixing rules, if the rule author can express the fix automatically.
In this POC I just put down the base structure to demonstrate the capabilities. Something production-ready would also integrate with the CI, linting only the changed files, and post comments for errors it encounters.
Before moving further, I'd like to get some feedback. I am not aware of all the ongoing plans and how this would fit in the big picture. /cc @NixOS/nixpkgs-ci team and also @SuperSandro2000 that cares about linting a lot.
Things done
passthru.tests.nixpkgs-reviewon this PR. See nixpkgs-review usage../result/bin/.Add a 👍 reaction to pull requests you find important.