A bit of an algorithm for adding config files:

For each config item, cycle through the active config files.
- Find an active file (in order of priority) that is applicable to this config item by indexing (if we can't find one there's a problem!)
- If the config item has no parent keys (flat config), add it to that file.
- Otherwise, the item has parent keys. Iterate through the keys starting with the root key, each time checking which active, applicable files contain it.
  - If we reach a point where only one such file contains it, add it to that file.
  - Otherwise, if we reach a point where no such files contain it, backtrack one key level (possibly to the root level) and add it to the highest-priority file.
  - Otherwise, we have iterated through all the keys and the section already exists in multiple files, in which case again we should add it to the highest-priority file, although in practice this means that the config has already been added - when we try to add a config section that's already added (in any case), we should pass the function without doing anything.

There's a complication with the above though... It assumes that there's a single key sequence to iterate over for each config file. But each file is potentially different. One thing we can check is whether they are actually different... if the ConfigEntry
objects are the same for each path then there's no issue. But if there are different ConfigEntry objects (or, at least, the objects have
different key sequences) then there's no sure-fire way to determine how one will or won't override the other. One heuristic might be to look at key depth (i.e. total number of strings deep we are) but I figure that might break down easily in a case (which I expect to be quite common) where a disambiguating [tool.xyz] section occurs in pyproject.toml which occurs at the root level in a bespoke config file (leading to an off-by-one issue in counting key levels.) This would only arise with esoteric resolution methodologies so for now I'm just leaving this issue for now and I will raise NotImplementedEror if this case ever arises. At the moment I only need to support the "first" resolution methodology since all the existing tools use that approach.

Properly handle other ruff configuration files #219

Description

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions