Using `ruff check --select` with `import-outside-top-level (PLC0415)` does not respect `flake8-tidy-imports.banned-module-level-imports`

[olivierdelree]

Summary

I am currently in the process of linting a codebase and have selected PLC0415 and TID253 as rules (among many others).
Since there are usually a lot of different rule violations when I enable a certain set of rules, I tend to work on a single rule at a time. To do that, I run ruff check --statistics and select the code of a rule I want to fix. Once I have the code, I run ruff check --select CODE and work from there.

As I understand it, this tells ruff to select only that rule to check. However, in the case of PLC0415, it gives me unexpected results as it does not respect the banned module level imports described in the flake8-tidy-imports.banned-module-level-imports list.
Strictly speaking, ruff is doing exactly what I am asking it to, checking only for PLC0415 violations. However, since that specific rule interacts with another one, TID253, it flags more violations than when running ruff check and can cause some confusion.

My expectation for ruff check --select CODE still considering interactions with related rules might very well be wrong and if so I'd happily accept a wont-fix but it would be more intuitive in my opinion to consider related rules, requiring a --ignore to, well, ignore them if necessary.

Example

Code

# issue.py
def foo() -> int:
    import random

    return random.randint(0, 10)

Config

# pyproject.toml
[ruff.lint]
select = [
    "TID253",   # banned-module-level-imports
    "PLC0415",  # import-outside-top-level
]

[ruff.lint.flake8-tidy-imports]
banned-module-level-imports = [
    "random",
]

Commands

$ ruff check 
All checks passed!

$ ruff check --select PLC0415
issue.py:2:5: PLC0415 `import` should be at the top-level of a file
  |
1 | def foo() -> int:
2 |     import random
  |     ^^^^^^^^^^^^^ PLC0415
3 |
4 |     return random.randint(0, 10)
  |

$ ruff check --select PLC0415,TID253
All checks passed!

Version

0.12.3

[ntBre]

I think this is surprising too. It came up a couple of weeks ago when documenting the link between the two rules: #18733 (comment). I think it would make sense always to respect the config option even if TID253 isn't enabled, but I'm curious if anyone disagrees. We'd probably need to make that change in preview, although it will only lead to fewer diagnostics rather than any new ones.

ruff/crates/ruff_linter/src/rules/pylint/rules/import_outside_top_level.rs

Lines 72 to 75 in 1ea5d8f

	// Check if any of the non-top-level imports are banned by TID253
	// before emitting the diagnostic to avoid conflicts.
	if checker.is_rule_enabled(Rule::BannedModuleLevelImports) {
	let mut all_aliases_banned = true;

[MichaReiser]

I think always honoring the option does make sense to me. It seems as explicit as enabling the rule.

, although it will only lead to fewer diagnostics rather than any new ones.

This can still be breaking because it means that some noqa comments are now unused.