v0.1.6: Overriding sub-setting category nulls other inherited settings (#4348)

[LTourinho]

Very similar to the issue described in #4348. I have a root dir with a file that looks a bit like:

proj/.ruff.toml:

[lint.isort]
section-order = ["standard-library", "common_pkgs", "third-party", "same_subcomp"]
[lint.isort.sections]
"common_pkgs" = ["numpy", "behave", ]
"same_subcomp"= []

proj/subdir/.ruff.toml:

extend = "../.ruff.toml"
[lint.isort.sections]
"same_subcomp" = ["<pattern>"]

Using a command such as ruff proj/subdir/<some_file> returns me an error like:

warning: section-order contains unknown section: UserDefined("common_pkgs")

Which means that isort.sections is being completely overwritten, when I expected to only overwrite the value of "same_subcomp". I can also confirm that the sorting of imports is not behaving as expected, as it will put numpy in the middle of the third party, when I want it to have its own block.

If this is the intended behavior, which I assumed it wasn't given issue #4348, is there a simple way I can achieve my intended behavior without copying the definition of common_pkgs to the .ruff.toml in every subdir?

Thanks in advance.

[charliermarsh]

Yeah, I think this should probably be considered a bug.

[LTourinho]

Hi, I see that the PR is approved and checks are green. What would be the ETA on this bugfix delivery?

[charliermarsh]

@LTourinho -- It's technically a breaking change, so it will go out in v0.3.

[charliermarsh]

@LTourinho -- Sorry for the delay, we decided to defer this to v0.4 because we need to figure out a way to allow extended configs to unset these.

[LTourinho]

@LTourinho -- Sorry for the delay, we decided to defer this to v0.4 because we need to figure out a way to allow extended configs to unset these.

No problem. Is the suggestion of setting to an "empty" object too bad in that regard? (The comment I made on the PR)

[LTourinho]

Hi @charliermarsh, as the PR was closed, what are the plans on fixing this issue?

[MichaReiser]

Hi @charliermarsh, as the PR was closed, what are the plans on fixing this issue?

Sorry that was not intentional. I cleaned up my stale branches and thought it's safe to delete any branch starting with charliemarsh. I restored the branch and reopened the PR.

[charliermarsh]

Thanks Micha, I meant to ask about that too :)

[LTourinho]

Hi guys, is there a reason this was postponed to 0.5? No agreement on how to unset values?

[MichaReiser]

Hi guys, is there a reason this was postponed to 0.5? No agreement on how to unset values?

There was no specific reason other than time constraints. We didn't want to block the 0.4 release by making this decision.

[charliermarsh]

0.4 was focused on the parser, we punted other breaking changes to 0.5 which we expect to release in the next few weeks.

[LTourinho]

Hi, I see that the previous solution pull request was closed. Is there no alternatives? Is this being picked up in any way?

[MichaReiser]

Unfortunately, I know of no alternative. We aren't actively working on this right now but are open to ideas. As little as I like that, a short-term solution could be an extend option. This comment explains why the other PR was closed)

[LTourinho]

Could there be a different keyword? E.g.: merge-into = "../.base_ruff.toml"

Then the breaking functionality would only happen to those who explicitly use the new keyword.

[MichaReiser]

Could there be a different keyword? E.g.: merge-into = "../.base_ruff.toml"

I would prefer not to but I won't rule it out. Either way, deciding on adding a different extension strategy isn't something we want to do lightly because it adds a lot of complexity and also makes it harder for users to understand what's happening.

[KotlinIsland]

• Related (duplicate?) Allow configuration to be defined on a file-scoped basis #7696