Repository navigation
Consider adding an option to supress ruff format CLI warnings #8185
Description
Activity
Thanks for reporting. Which of the conflicting rules do you want to use alongside the formatter and what's the use case for having both enabled (what do they catch in addition to the formatter)?
(It sounds like one example is: using isort with different settings; so you run the formatter, then linter, to get formatted code with different import settings (which would then be reformatted if you re-ran the formatter).)
Yeah I use
force-single-line = truefrom isort (was using it with black as well).I also have a warning about a bunch of other conflicts ('D206', 'E501', 'ISC001', 'Q000', 'Q001', 'Q002', 'Q003', 'W191').
My configuration might be weird, I have
select = ["ALL"]and a few groups inignore. I prefer to do it this way because:- I get to test all the new rules when updating
- It's a smaller config to disable the few rules I don't want.
And actually if I stop running
ruff check, ruff format is not reformatting anything, so I'm not too sure if there is really a conflict?Also I would not want to disable all ruff warnings, only these rule conflict warnings.
Reacted by Tyler C Laprade, CFA and Aldo D'AquinoI hit this as well, with a very vanilla configuration - no custom isort options, etc. but we have a blanket
select = ["E", "W", …]which means I see this:warning: The following rules may cause conflicts when used with the formatter: 'E501', 'W191'. To avoid unexpected behavior, we recommend disabling these rules, either by removing them from the
selectorextend-selectconfiguration, or adding then to theignoreconfiguration.The W191 seems like it could only be displayed when you have customized the formatter to use tabs instead of spaces.
E501 seems like a harder case since most of the time it won't be an issue but there are a difficult cases (long comments, etc.) where it might be an issue. I wonder whether this might be as simple as implementing #8175 or trying something clever see whether the
format + lintcombination is stable before emitting it so the warning could be strengthened from “may cause conflicts” to “is causing conflicts with your configuration”.Reacted by Avasam, Tyler C Laprade, CFA and Muhammad YasirroniThanks for explaining.
We intentionally allow E501 because some projects use E501 to warn about extra long lines (e.g. line-length: 80 and pycodestyle.max-line-length: 100).
The W191 seems like it could only be displayed when you have customized the formatter to use tabs instead of spaces.
I like this
!!! You guys are fast, well done! It's a bit better, I get different ones now.
I'm still not convinced by the warnings. If we take the linter as an example, there is not such warning and it's up to the user to make sure they didn't activate conflicting rules isn't it?
Moreover, I still don't understand how the rules included in the warning conflict with the formatter with default settings: ('D206', 'E501', 'ISC001', 'Q000', 'Q001', 'Q002', 'Q003', 'W191')
!!! You guys are fast, well done! It's a bit better, I get different ones now.
Did you build from source? The changes are not yet released.
!!! You guys are fast, well done! It's a bit better, I get different ones now.
Did you build from source? The changes are not yet released.
Yes yes I used the master branch from a few minutes ago. I no longer have the conflict about
force-single-linefrom isort.Oh nice! Can you try #8196? It isn't yet merged. Feel free to comment directly on the PR.
5 remaining items
Perhaps we could combine this request with a mechanism by which we automatically disable conflicting lint rules and options -- something like
formatter-compatibility = warn | ignore | force.Reacted by deadnews, MithicSpirit and Dhruv ManilawalaPerhaps we could combine this request with a mechanism by which we automatically disable conflicting lint rules and options -- something like
formatter-compatibility = warn | ignore | force.That sounds interesting. I recommend making such option tooling independent (e.g. disabling conflicting rules etc). Having a tool specific name also opens the question of where it should be placed in the configuration. Under
format, or better lint?If we take the linter as an example, there is not such warning and it's up to the user to make sure they didn't activate conflicting rules isn't it?
We actually do have warnings in the linter like this too e.g.
❯ ruff check . --select ALL warning: `one-blank-line-before-class` (D203) and `no-blank-line-before-class` (D211) are incompatible. Ignoring `one-blank-line-before-class`. warning: `multi-line-summary-first-line` (D212) and `multi-line-summary-second-line` (D213) are incompatible. Ignoring `multi-line-summary-second-line`.I recommend making such option tooling independent
What do you mean? Like
ruff.on-tool-configuration-conflictinstead ofruff.tool.format.on-linter-conflict?I recommend making such option tooling independent
What do you mean? Like
ruff.on-tool-configuration-conflictinstead ofruff.tool.format.on-linter-conflict?Kind of, but ideally more generic:
configuration-conflict = "warn" | "resolve"Because there are other conflicts. E.g. you could setpycodestyle.line-lengthto a lower limit than theline-lengthand that will lead to incompatibility withisortand the formatter. We could probably come up with a better name. There are also conflicts between the same tool as your example shows (conflict between lint rules)Alternatives:
configuration-conflict-resolution = "manual" | "automatic" | "silent"(automaticresolves conflicts but warns). Although I'm not sure how I feel aboutsilentHm that seems really broad... I probably want different behavior depending on the category of conflict but perhaps this is a good start. Maybe
on-configuration-conflict = "error" | "warn" | "ignore"?Perhaps we could combine this request with a mechanism by which we automatically disable conflicting lint rules and options -- something like
formatter-compatibility = warn | ignore | force.Well I opened this issue with this in mind, but when I see all the great work aiming at making the warnings represent actual conflicts and remove false-positive, I'm not sure it's really necessary anymore.
Don't know about others, but #8196 and #8244 will probably remove all the warnings for my use cases.
We shipped some improvements in the last release. Please open a new issue if you still encounter issues and would prefer having an option to suppress all format CLI warnings.
@MichaReiser Thanks for the work this is great. I see you choose not to add
ISC001in your PR in the end, is there a specific reason to that?In
ruff check, there's always an option to runruff check . --select=ALL 2>/dev/nullif you can't fix the incompatibilities and want to ignore all warnings, as they get written to stderr.I usually do not use the ruff formatter directly, thus only talking about
ruff check.This is a very "nuclear" practice, but suppresses the annoying warnings.
I hit this as well, with a very vanilla configuration - no custom isort options, etc. but we have a blanket
select = ["E", "W", …]which means I see this:warning: The following rules may cause conflicts when used with the formatter: 'E501', 'W191'. To avoid unexpected behavior, we recommend disabling these rules, either by removing them from the
selectorextend-selectconfiguration, or adding then to theignoreconfiguration.The W191 seems like it could only be displayed when you have customized the formatter to use tabs instead of spaces.
E501 seems like a harder case since most of the time it won't be an issue but there are a difficult cases (long comments, etc.) where it might be an issue. I wonder whether this might be as simple as implementing #8175 or trying something clever see whether the
format + lintcombination is stable before emitting it so the warning could be strengthened from “may cause conflicts” to “is causing conflicts with your configuration”.What is the recommended solution for this @acdha?
Edit: turns out, simply update to the latest ruff version solved it.
Just tried
ruff format, it's seriously great!I'm just annoyed by the warnings showing up in console:
warning: The following rules may cause conflicts when used with the formatter: XXXI want my linter (specifically the isort part) taking priority over the formatter, so I run the linter after the formatter and never had problems.
Is there any way to acknowledge / supress the CLI warnings with a configuration option or a command line parameter?