-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Per file selection #3172
Comments
I suspect that the last option would be much easier to support than |
(The way |
This feature will be useful for big repositories (eg. PyTorch) to incrementally adopt stricter rules in different components. Potentially run checks on all rules from the per-file-select as well for everyone, then suppress for files not in this group? |
It's useful for small repositories as well. 👀 |
If someone wants to work on this, I'd be happy to review a proposal. I expect there to be some prototype / design work. |
Leaving my notes here in case another contributor wants to pick this up. The glob mechanism in Ruff is based on globset, and it looks like the options supported there are supported in Ruff. The only negation option that's supported is single character negation (e.g., Extended globbing has negation, which could work, but extended globs are not likely to be supported by globset: BurntSushi/ripgrep#2608 globset is part of the ripgrep project. Ripgrep allows negation by using a The (And yes, I do realize that this was a lot of work to reach exactly what @henryiii suggested in his third bullet point 😂 Hopefully this helps other curious folks save themselves some time/effort.) @zanieb Does the |
I'm supportive of adding negations via |
I'm supportive as well. Is someone interested in putting up a prototype? |
I think @carljm may be interested. |
Fixes #3172 ## Summary Allow prefixing [extend-]per-file-ignores patterns with `!` to negate the pattern; listed rules / prefixes will be ignored in all files that don't match the pattern. ## Test Plan Added tests for the feature. Rendered docs and checked rendered output.
See some discussion at #10863 (comment) on how negative patterns should behave when the pattern does match the file (i.e. the negative pattern doesn't hit). Should this "un-ignore" the listed patterns, or do nothing (patterns are always only additive to what's ignored)? |
Refs #3172 ## Summary Fix a typo in the docs example, and add a test for the case where a negative pattern and a positive pattern overlap. The behavior here is simple: patterns (positive or negative) are always additive if they hit (i.e. match for a positive pattern, don't match for a negated pattern). We never "un-ignore" previously-ignored rules based on a pattern (positive or negative) failing to hit. It's simple enough that I don't really see other cases we need to add tests for (the tests we have cover all branches in the ignores_from_path function that implements the core logic), but open to reviewer feedback. I also didn't end up changing the docs to explain this more, because I think they are accurate as written and don't wrongly imply any more complex behavior. Open to reviewer feedback on this as well! After some discussion, I think allowing negative patterns to un-ignore rules is too confusing and easy to get wrong; if we need that, we should add `per-file-selects` instead. ## Test Plan Test/docs only change; tests pass, docs render and look right. --------- Co-authored-by: Alex Waygood <[email protected]>
Fixes astral-sh#3172 ## Summary Allow prefixing [extend-]per-file-ignores patterns with `!` to negate the pattern; listed rules / prefixes will be ignored in all files that don't match the pattern. ## Test Plan Added tests for the feature. Rendered docs and checked rendered output.
…#10863) Refs astral-sh#3172 ## Summary Fix a typo in the docs example, and add a test for the case where a negative pattern and a positive pattern overlap. The behavior here is simple: patterns (positive or negative) are always additive if they hit (i.e. match for a positive pattern, don't match for a negated pattern). We never "un-ignore" previously-ignored rules based on a pattern (positive or negative) failing to hit. It's simple enough that I don't really see other cases we need to add tests for (the tests we have cover all branches in the ignores_from_path function that implements the core logic), but open to reviewer feedback. I also didn't end up changing the docs to explain this more, because I think they are accurate as written and don't wrongly imply any more complex behavior. Open to reviewer feedback on this as well! After some discussion, I think allowing negative patterns to un-ignore rules is too confusing and easy to get wrong; if we need that, we should add `per-file-selects` instead. ## Test Plan Test/docs only change; tests pass, docs render and look right. --------- Co-authored-by: Alex Waygood <[email protected]>
I'd like a way to activate a rule for a subset of files; basically the inverse of per-file-ignores. In my case, I'd like to activate pydocstyle on the main module, but not tests, examples, docs, benchmarks, support files, setup.py, etc.
Current and possible options:
.ruff.toml
(Additional configuration file.ruff.toml
#2988) would help a little, but still not my preferred solution for this case - I'd like all configuration in a single file.tool.ruff.per-file-extend-select
(technically,per-file-ignores
is also extend, so maybe for symmetry it could betool.ruff.per-file-extend-select
). This would then be"src/**.py" = ["D"]
.tool.ruff.per-file-ignores
like a gitignore. So"!src/**.py" = ["D"]
would ignore D on anything exceptsrc/**.py
files.Thoughts?
Here's what I would have to put without this:
The text was updated successfully, but these errors were encountered: