isort with multiple config files does not work correctly

[AbdealiLoKo]

Describe the bug
I have a project like:

libs
    lib1
        pyproject.toml
        lib1
            ... files in the lib
        lib1_test
            ... tests for the lib
    lib2
        ... similar to lib1
    ... more libs

And I am using pyproject.toml for the isort configs:

[tool.isort]
profile = "pycharm"
skip_glob = ["venv*"]
line_length = 110
known_first_party = ["lib1", "lib1_test"]
combine_as_imports = true
force_grid_wrap = 0
include_trailing_comma = true
order_by_type = false
case_sensitive = true

And the pyproject.toml for every lib changes the known_first_party = ["lib1", "lib1_test"] to treat only the library as a first party import.

When I run: ./pants fmt :: - it was using the wrong first party imports
On @benjyw 's suggestio - tried: ./pants fmt libs/lib1/:: And it seemed to work

After a lot of digging, I realized that isort finds the config file based on the 1st file provided to it
https://pycqa.github.io/isort/docs/configuration/config_files.html
And order of files that pants is sending into isort is mosst likely the culprit here.

Pants version: 2.13.0
OS: Windows 10 + Ubuntu 18.04 LTS

Additional info
Slack conversation: link
Another issue related to isort I checked: #15069
The batch ID concept in this issue may have been a workaround here: #14941

[thejcannon]

In this case I believe the solution would be to partition the inputs (files) based on config such that no two files passed to isort would disagree on config.
This is how we run scalafmt:

pants/src/python/pants/backend/scala/lint/scalafmt/rules.py

Line 125 in 97c4ede

async def partition_scalafmt(

[AbdealiLoKo]

On discussion with @Eric-Arellano This issue does not seem to be present with isort4
In isort4 - the config files were not based on the "first input provided to isort" (althought I don't have any lear documentation to referencec here)

I tried:

$ venv/bin/pip install -U 'isort<5'
Successfully installed isort-4.3.21

$ venv/bin/isort lib2 lib1 <---- Formatted something
Fixing lib2/lib2/__init__.py
Fixing lib1/lib1/__init__.py

$ venv/bin/isort lib1 lib2 <----- FLIP: nothing to fix.

$ venv/bin/pip install -U isort 
Successfully installed isort-5.10.1

$ venv/bin/isort lib2 lib1 <---- Formatted something
Fixing lib2/lib2/__init__.py
Fixing lib1/lib1/__init__.py

$ venv/bin/isort lib1 lib2 <----- FLIP: Still has something to fix
Fixing lib1/lib1/__init__.py
Fixing lib2/lib2/__init__.py

[Eric-Arellano]

From Slack:

Looks like there is a argument --resolve-all-configs which follows the older behavior of getting a config file for every file provided as input

@AbdealiJK can this be closed, then? Is that working?

[AbdealiLoKo]

Yep - closing.
I am still seeing some weird behavior. Specifically in this structure:

my_api
pyproject.toml
libs/
    lib1
        lib1
        pyproject.toml

But when I run: venv/bin/pants fmt lib/lib1/lib1 it considers my_api as a 3rd party import
And running: venv/bin/pants fmt :: it considers my_api as a 1st party import

But I assume this is because isort --resolve-all-configs merges the root pyproject.toml with the libs/lib1/pyproject.toml file.

So, I think that is because of the sandbox not having all the files - maybe same as: #15069

[benjyw]

Yeah, that last issue sounds like #15069, and the workaround is to explicitly list your 1stparty packages in isort config.