epage
commented
2 months ago For myself, I find this true of a lot of aspects of my project (github actions, tool settings, etc) and I keep a repo of all of that (https://github.com/epage/_rust). I periodically merge this into each of my repos (would be great to automate). For repos that weren't forked off of this, I used git merge --allow-unrelated-histories. The main limitation is propagating package-level information in a workspace.
If we were to do something like this, we can add the sub-table as we've reserved all tool names though it blocks that name from ever being used by a tool (like lints.workspace does).
We would need to deal with
- Fully specifying the source. Likely this wouldn't just be git rev/tag/branch but finding a specific location within the git repo
- Potentially locking the source with a way to update it
- Defining the source format (just another manifest? a custom format)
Another odd aspect of this is it being present in dependencies. iirc we apply the lint table within a dependency but to apply this would have us pulling arbitrary locations, ones that might not exist anymore, which would also slow things down. We might be able to say "eh, cap-lints means we likely won't be affected" and just drop these lints.
Problem
Description
It would be really great to be able to centralize lint configurations across packages. The current limitations mean that, if a team maintains 20 packages in different repos, they will need to manage each package separately.
Is this something we'd be interested in adding?
Proposed Solution
I'd think we could have a feature where we could add something like:
to
Cargo.toml.Notes
No response