Do I understand the difference between "--select" and "--extend-select" correct?

[buhtz]

I was not able to find an appropriate explanation of that difference. The docs them self should be updated. They are not clear about it.

When I use "--select" ALL rules are disabled except the ones I list via "select"? So no default rules are active anymore?

When I use "--extend-select=" the default rules are still active?

Today ruff is to old and established to modify that behavior. But it is unusual and it should be taken into account for the next major release to modify that. "extend-select" should be removed and "select" should behave like "extend-select".

The problem and IMHO unusual behavior is that "--select" has the implicit behavior to disable ALL rules. That is unexpected to most users I assume.

I was surprised not finding any earlier discussion about that topic. I assume there is one somewhere in the internet. I assume I am not the first one morning about that behavior.

[MichaReiser]

You're understanding is correct and this is documented here

Another way to think about it is that:

• select: Replaces the rules or sets the rules explicitly
• extend-select: Adds new rules to what's configured by select

Today ruff is to old and established to modify that behavior. But it is unusual and it should be taken into account for the next major release to modify that. "extend-select" should be removed and "select" should behave like "extend-select".

extend-select is essential to support configuration inheritance when using the extend option. It is crucial because most users want to add new rules in addition to what the base configuration specifies. However, that's not always the case; that's where users can use select to override the rules from the base configuration explicitly.

[buhtz]

Brings me to a follow up question: What is a real use case for "--extend". The doc gives an example where one pyproject.toml includes another pyproject.toml. I would argue that a project is missconfigured if there are two pyproject.toml files.

[MichaReiser]

It's a common use case if you have mono repositories that contain multiple project. You may want to establish a base standard for the entire company but allow projects to customize the configuration so that it best fits their needs. That's where extend is useful

[buhtz]

OK, I got it. But I think there is a (good) reason why the Python folks refused to add a feature (PEP) where one "pyproject.toml" can inherit from another. IMHO other tools shouldn't work around that restriction. Adds to much complexity. The use case you describe indicates problems in project management and design.