I have a repo with this tree: ``` directory_root packageA setup.cfg module1.py module2.py packageB module3.py ``` With `packageA/module1.py` having the following contents: ```python import module2 import packageB import numpy import os ``` and `packageA/setup.cfg` having the following contents: ``` [isort] known_first_party = bla ``` If I run isort with: `python -m isort --verbose --check-only packageA/module1.py packageA/module2.py packageB/module3.py` I get the following output: ``` _ _ (_) ___ ___ _ __| |_ | |/ _/ / _ \/ '__ _/ | |\__ \/\_\/| | | |_ |_|\___/\___/\_/ \_/ isort your imports, so you don't have to. VERSION 5.11.2 else-type place_module for module2 returned FIRSTPARTY else-type place_module for packageB returned THIRDPARTY else-type place_module for numpy returned THIRDPARTY else-type place_module for os returned STDLIB ERROR: /directory_root/packageA/module1.py Imports are incorrectly sorted and/or formatted. SUCCESS: /directory_root/packageA/module2.py Everything Looks Good! SUCCESS: /directory_root/packageB/module3.py Everything Looks Good! ``` which is what I expected. So if I run isort without *--check-only* option, the original `packageA/module1.py` file is reformatted to: ```python import os import numpy import packageB import module2 ``` However, I want to start having [support for multiple config files in a single isort run](https://pycqa.github.io/isort/docs/configuration/config_files.html#supporting-multiple-config-files-in-single-isort-run), so I have to use the `--resolve-all-configs` argument: `python -m isort --verbose --resolve-all-configs --check-only packageA/module1.py packageA/module2.py packageB/module3.py` which gives me the following output: ``` _ _ (_) ___ ___ _ __| |_ | |/ _/ / _ \/ '__ _/ | |\__ \/\_\/| | | |_ |_|\___/\___/\_/ \_/ isort your imports, so you don't have to. VERSION 5.11.2 ./packageA/setup.cfg used for file packageA/module1.py ERROR: /directory_root/packageA/module1.py Imports are incorrectly sorted and/or formatted. ./packageA/setup.cfg used for file packageA/module2.py default used for file packageB/module3.py ``` ___ ***First Question:*** Why is the verbose debug information different when using the `--resolve-all-configs` argument? The `else-type place_module for <some_import> returned <SECTION_NAME>` messages are gone, as well as the `SUCCESS: <some_file> Everything Looks Good!` message. ___ Now, let's see the reformatting result when I run with argument `--resolve-all-configs` and without *--check-only* option: ```python import os import module2 import numpy import packageB ``` To me this is quite unexpected, *packageB* went from THIRDPARTY to FIRSTPARTY and *module2* went from FIRSTPARTY to THIRDPARTY. ___ ***Second Question:*** (related to known_first_party inconsistencies!) Why is the sorting result different when using or not the the `--resolve-all-configs` argument, if the config .cfg file used is the same? If the same `packageA/setup.cfg` is used, I would expect the same sorting result. ___ Furthermore, I noticed using `--resolve-all-configs` argument makes isort much slower, taking a couple seconds for such a simple repo. However, I also noticed that adding more folders/packages makes isort even slower, even if the request is exactly the same (sorting module1/2/3 only in package A and B). For example, if I added 20 more packages (`packageC`, `packageD`, ..., `packageZ`), with plenty of folders inside each one, the isort run with the `--resolve-all-configs` argument took almost 20 seconds, even if only 3 modules in 2 packages are being reformatted. ___ ***Third Question:*** Why does isort with `--resolve-all-configs` argument become slower when adding more folders/packages, even if it is still sorting the same number of files? Shouldn't the search for the closest config file happen only for the files that are requested to sort, thus making isort run time only dependent on the number of files to check/reformat instead of the repo size? ___ Finally, I went back to testing the isort standard behavior when using only a single config file (*without* the `--resolve-all-configs` argument). I changed the `packageA/setup.cfg` file by removing the known_first_party entry, thus making it empty, which I expect to make it resort to default configuration: ``` [isort] ``` If I run isort again with: `python -m isort --verbose packageA/module1.py packageA/module2.py packageB/module3.py` I get the following output: ``` _ _ (_) ___ ___ _ __| |_ | |/ _/ / _ \/ '__ _/ | |\__ \/\_\/| | | |_ |_|\___/\___/\_/ \_/ isort your imports, so you don't have to. VERSION 5.11.2 else-type place_module for module2 returned THIRDPARTY else-type place_module for packageB returned FIRSTPARTY else-type place_module for numpy returned THIRDPARTY else-type place_module for os returned STDLIB Fixing /directory_root/packageA/module1.py ``` which reformats the original file in this way: ```python import os import module2 import numpy import packageB ``` Again, compared to the original configuration, *packageB* went from THIRDPARTY to FIRSTPARTY and *module2* went from FIRSTPARTY to THIRDPARTY. ___ ***Fourth (and Final) Question:*** (related to known_first_party inconsistencies!) Why do both *packageB* and *module2* change sections if I have a default configuration vs `known_first_party = bla`, where `bla` was not even a package existing in my repo? ___ For `module1` formatting, I expected always to have `module2` as FIRSTPARTY because it's part of the same python package and lives in the same directory, and `packageB` as THIRDPARTY because it's a separate package from `packageA` where `module1` lives. And why setting known_first_party to some specific name would have an impact? Does it replace the default FIRST_PARTY, or extend? Additionally and probably the most important question in this issue, why does `--resolve-all-configs` argument change the sorting result if exactly the same config file is applied?