Please add "is `default` rule" info to the rule json data

[idanmiara]

Hi,
I think it would be useful to add an default key to the json root info and/or to the status inner dict, per rule,
i.e. ruff rule YTT101 --output-format json could output something like:

  "name": "sys-version-slice3",
....
  "default": True,
  "status": {
    "Stable": {
      "since": "v0.0.113"
    },
    "default": {
      "since": "v0.16.0"
    }
  },

if a rule is ever dropped from the default list, maybe mark it accordingly, like:

  "default": False,
  "status": {
    "Stable": {
      "since": "v0.0.113"
    },
    "default": {
      "since": "v0.16.0",
      "until": "v0.30.0"
    }
  },

related to:
#27213
#28190

[ntBre]

This is also related to #27666 (comment), but the categories themselves determine the defaults. I'm not really opposed to adding a default field if others would find it useful, but you can currently check this by testing if the category field is correctness, suspicious, complexity, performance, or style. This is described in the docs here, but I'm also working on a better way to present this in #28099.

[idanmiara]

This is also related to #27666 (comment), but the categories themselves determine the defaults. I'm not really opposed to adding a default field if others would find it useful, but you can currently check this by testing if the category field is correctness, suspicious, complexity, performance, or style. This is described in the docs here, but I'm also working on a better way to present this in #28099.

Thanks for your prompt reply!
Are the rules set in these 5 categories exactly the same rules that are marked as default with preview=False?

[ntBre]

Ah no, that's a good point. The preview categories include preview rules and also a few other changes made as part of recategorization, so checking the categories is only fully accurate on preview.

This is a lot hackier, and thus probably supports adding the feature requested here 😆 but I've been doing a lot of analysis of default rules and often use a command like this to extract them:

❯ ruff check --isolated --show-settings | awk '/linter.rules.enabled/,/]/' | head
linter.rules.enabled = [
        sys-version-slice3 (YTT101),
        sys-version2 (YTT102),
        sys-version-cmp-str3 (YTT103),
        sys-version-info0-eq3 (YTT201),
        six-py3 (YTT202),
        sys-version-info1-cmp-int (YTT203),
        sys-version-info-minor-cmp-int (YTT204),
        sys-version0 (YTT301),
        sys-version-cmp-str10 (YTT302),

Note that it requires at least a dummy Python file in the working directory, though, which might be a separate bug.

[idanmiara]

Ah no, that's a good point. The preview categories include preview rules and also a few other changes made as part of recategorization, so checking the categories is only fully accurate on preview.

This is a lot hackier, and thus probably supports adding the feature requested here 😆 but I've been doing a lot of analysis of default rules and often use a command like this to extract them:

❯ ruff check --isolated --show-settings | awk '/linter.rules.enabled/,/]/' | head
linter.rules.enabled = [
sys-version-slice3 (YTT101),
sys-version2 (YTT102),
sys-version-cmp-str3 (YTT103),
sys-version-info0-eq3 (YTT201),
six-py3 (YTT202),
sys-version-info1-cmp-int (YTT203),
sys-version-info-minor-cmp-int (YTT204),
sys-version0 (YTT301),
sys-version-cmp-str10 (YTT302),
Note that it requires at least a dummy Python file in the working directory, though, which might be a separate bug.

Thanks for the pointer!
Is there a similar command for printing the default rules in preview mode ?

[ntBre]

You can use --preview with --isolated:

❯ ruff check --isolated --show-settings | awk '/linter.rules.enabled/,/]/' | wc -l
     415
❯ ruff check --preview --isolated --show-settings | awk '/linter.rules.enabled/,/]/' | wc -l
     496

and if you want the enabled rules for your project, you can just omit --isolated. That's the variant I actually use most often.

But yeah, if you're back in preview mode, then this should also work:

❯ ruff rule --all --output-format=json | jq 'map(select(.category | IN("correctness", "suspicious", "complexity", "performance", "style"))) | length'
498

Although that revealed one more wrinkle with relying on the category from ruff rule. We ended up assigning categories to removed rules too. The four removed rules with default categories account for the 496 (-2 lines for the start and end of the linter.rules.enabled array) vs 498 reported by the two commands. jq can handle that too, but it's getting pretty wild:

❯ ruff rule --all --output-format=json |
  jq 'map(
    select(.category | IN("correctness", "suspicious", "complexity", "performance", "style"))
    | select(.status | has("Removed") | not)
  ) | length'
494