Warnings about incompatible rules with --select ALL

[DimitriPapadopoulos]

I'd rather not see warnings about incompatible rules with --select ALL. Do the folowing warnings about incompatible rules appear by default on purpose with --select ALL?

• """Documentation."""

• $ ruff --isolated --select ALL file.py
  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`.
  $ 
  

• $ ruff --version
  ruff 0.1.3
  

[zanieb]

If you don't want the warnings, I'd recommend explicitly ignoring two of those rules (whichever you do not want). In general, we do not recommend usage of --select ALL.

[charliermarsh]

Yeah, these are intended, because the rules are legitimately in conflict. Ideally, we will resolve this when do recategorize the rules in the future. At present, the only other option I see is to straight-up omit those two specific rules (D203 and D213) from ALL, which could also cause confusion in the other direction (though would be much more rare).

[charliermarsh]

(We could also consider removing those rules.)

[DimitriPapadopoulos]

It makes sense. However, newcomers who start with ruff check --help see:

$ ruff check -h
Run Ruff on the given files or directories (default)
[...]
Rule selection:
      --select <RULE_CODE>
          Comma-separated list of rule codes to enable (or ALL, to enable all rules)
      --ignore <RULE_CODE>
          Comma-separated list of rule codes to disable
[...]

[DimitriPapadopoulos]

They might be tempted to use option --select ALL. The result is that they see these warnings, which do make sense but might be disturbing for first time users.

[MichaReiser]

It could make sense to remove ALL from the CLI help. It isn't our recommended way of using ruff and is overused.

[zanieb]

@MichaReiser I think that may make sense after recategorization

[MichaReiser]

@MichaReiser I think that may make sense after recategorization

What's your motivation for waiting until after recatogorization? I'm only proposing to remove it from the help text to promote it less. It may also be the case that we won't have a way to run all rules after recategorization (without listing all categories)

[zanieb]

@MichaReiser I see the presence of sensible categories as essential to replace ALL. Until then, I worry we'll just get more questions if we remove the hint.

[charliermarsh]

I don't think we should remove it from help, etc., until we have a reasonable alternative.

[charliermarsh]

I do think we could consider removing these rules from ALL.

[zanieb]

I don't have a strong preference on removal from ALL but find excluding rules from ALL a weird pattern.

I'd rather close in favor of #1774

[charliermarsh]

It's weird, but so is the behavior here, and I do dislike that it's so common to run into these warnings when the rules themselves are so uncommon.

[tmeiczin]

We have over a million lines of code and currently use ALL and disable about 40 rules (0.1.5 without preview). Without the ALL would we need to explicitly enable all 700 something rules? Enable all the categories, then specify individual ones we want disabled? That seems like it would get awkward? Or maybe I'm just selecting them wrong as it is?

I think many of the formatters and linters (maybe to a lesser extent) are going to be somewhat opinionated. I'm ok with that provided there is a reasonable amount of flexibility to alter the behavior to suit my projects. Maybe in addition to ALL add a DEFAULT which is a curated selection and chooses or disables rules with conflicts. Or possibly something like a --select-conflict-defaults which allows to specify which rules are enabled in case of conflicts.

[MichaReiser]

We have over a million lines of code and currently use ALL and disable about 40 rules (0.1.5 without preview). Without the ALL would we need to explicitly enable all 700 something rules? Enable all the categories, then specify individual ones we want disabled? That seems like it would get awkward? Or maybe I'm just selecting them wrong as it is?

You would have to enable all categories that aren't enabled by default, which should only be a few (<10). The categories we're thinking about are similar to clippy's but with a few additional ones (e.g. format for formatting related lints)