Avoiding targets of past treewide fixes?

Browsing nixpkgs for something just now and noticed a treewide fix that is probably “wrong” in my local packages. This made me wonder how often things one or more people have taken effort to fix are innocently reintroduced in packages/edits patterned off older examples.

People who’ve made treewide fixes probably have a better sense of whether keeping them from creeping back in is a Sisyphean struggle or not.

I ran a search (https://github.com/NixOS/nixpkgs/search?utf8=✓&q=treewide&type=Commits) for the term to get a sense of how much effort I would need to get current, but there are quite a few, and the first few pages of results suggest a great many duplicate the same logical change(s).

If backsliding into these is an issue (and if they aren’t already being built into the Nix auto-formatter), it might help to have a bot/tool (or at least an auto-generated, de-duplicated checklist with links to examples?) that can flag these and link to a reasonably succinct example of how and why to get it right.

If this thing itself is useful, it might also be helpful if “treewide” commit messages trigger a nudge to the author to ensure the target of the edit makes it into the relevant tools and resources?

1 Like

The recent treewide changes are consequence of not yet merged https://github.com/NixOS/nixpkgs/pull/72074. Being split into multiple commits is more of an artefact how the fixes are generate (wait for CI, fix, repeat cycle). In this case, the PR includes assertions ensuring these changes do not regress but it is not always the case. We need some tool like hlint, that can check more than just syntactical changes when assertions are not possible for performance or other reasons, see https://github.com/NixOS/ofborg/issues/245.

2 Likes

@jtojnar Hoped you’d comment. Fair to interpret that to mean that you see a linter (probably nix-linter?) as more relevant than an auto-formatter such as nixfmt? Linking https://github.com/Synthetica9/nix-linter/issues/30 to create a web of references just in case :slight_smile:

Yeah, formatters are usually limited to syntactical changes but the treewide fixes are usually more complex than that. Not that I would undervalue auto-formatters – the more work can be automated, the better.

Yeah we really need a type system to not make mistakes working tree-wide in a single commit. Until then…well I’m sorry.

1 Like