search

NixOS / nixpkgs-vet

Tool to vet (check) Nixpkgs, including its pkgs/by-name directory
MIT License
31 stars 7 forks source link

Extend to not just `pkgs/by-name` #45

Open infinisil opened 7 months ago

infinisil commented 7 months ago

Recently there was an automated mass removal of lib.mdDoc which now requires subsequent PRs whenever a PR that introduces more instances gets merged.

The approach used by nixpkgs-check-by-name makes sure that this problem doesn't happen. We should consider integrating such treewide removals to benefit from that. This will also be relevant for the upcoming automated pkgs/by-name migration.

In particular, while this tool currently only has infrastructure for detecting when new instances of deprecated patterns are introduced, I've been planning to add infrastructure to also do automated replacements of such deprecated patterns.

For now I haven't gotten to that, but let's use this issue to track such developments.

stuebinm commented 6 months ago

In particular, while this tool currently only has infrastructure for detecting when new instances of deprecated patterns are introduced, I've been planning to add infrastructure to also do automated replacements of such deprecated patterns.

how would that look like? i have little idea of how the (i assume) relevant github APIs look like, nor of the check-by-name tool, but as I'm at fault for the mass-mdDoc removal & wrote the tool which did it, I could probably (if desired) write some kind of interface for it that's useful to this, either as a cli tool that can be called by this checker, or even as a rust crate, as it can already search for syntactic patterns & "edit" (read: currently only remove) them.

infinisil commented 6 months ago

@stuebinm Thanks for the interest! I just took the time to write it down in a high level here: https://github.com/NixOS/nixpkgs-check-by-name/issues/56. Turned out a bit long, but it's important context.

I think the nixpkgs-check-by-name tool is really on a good path towards becoming super useful for various future deprecations of Nixpkgs patterns. And the codebase is in a really good place right now, with clean code, lots of comments, documentation, tests and automation. Since moving it to this separate repo, I've also onboarded @philiptaron and @willbush with commit access and am very open to extending that. So if you're interested, please consider joining the effort in making this the best CI tool for Nixpkgs :D

While we primarily work asynchronously via GitHub, we sometimes use the Nixpkgs Architecture Matrix room or my weekly office hours to synchronise. Would be great if you could join those!