Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

isort doesn't respect config when it is inside subfolders #2200

Open
cedric-spinergie opened this issue Nov 23, 2023 · 3 comments
Open

isort doesn't respect config when it is inside subfolders #2200

cedric-spinergie opened this issue Nov 23, 2023 · 3 comments

Comments

@cedric-spinergie
Copy link

cedric-spinergie commented Nov 23, 2023

Context

I have a particular setup with a repo in which there are two folders containing python projects.
Those project each have their own pyproject.toml with their own config for isort.

If I run isort project1, everything works fine. Same with isort project2. However, if I do isort . from the root directory, isort doesn't seem to find the configuration and considers all firstparty imports to be thirdparty instead.

Reproduction

I have a reproduction repo for people to see what goes wrong.
It is available here: https://github.com/cedric-spinergie/isort-repro-2200

To be future proof

Structure

 > tree
.
├── django
│   ├── example.py
│   ├── pyproject.toml
│   └── setting.py
└── scripts
    ├── example2.py
    ├── pyproject.toml
    └── value.py

2 directories, 6 files

Files in django

django/pyproject.toml

[tool.isort]
profile = "black"
line_length = 120
sections = "FUTURE,STDLIB,THIRDPARTY,FIRSTPARTY,LOCALFOLDER"

django/example.py

import sys

import pandas

from setting import test


def my_example(request):
    print(test)

django/setting.py

test = "hello"

Files in scripts

scripts/pyproject.toml

[tool.isort]
profile = "black"
line_length = 120
sections = "FUTURE,STDLIB,THIRDPARTY,FIRSTPARTY,LOCALFOLDER"

scripts/example2.py

import sys

import pandas

from value import test2


def second_test(request):
    print(test2)

scripts/value.py

test2 = "hola"

The problem

As you can see, the main files django/example.py and scripts/example2.py each have 3 imports:

  • 1 stdlib import (sys)
  • 1 third party import (pandas)
  • 1 first party import (setting or value)

By default, those imports are properly separated ; showing that isort properly understands the category they each belong to.

Now, if we do isort django or isort scripts, nothing changes, as expected.
But if we do isort ., we'll see the main files change to put setting / value into the third party exports category.

I expect isort django, isort scripts and isort . to behave the exact same way and always result in the exact same code.

Fun facts:

  • isort django scripts will properly format django but mess up scripts.
  • isort scripts django will properly format scripts but mess up django.

The option --resolve-all-configs does not change anything. It's as if it were entirely ignored or maybe I misunderstood its purpose.

Version

  • isort 5.12.0
  • Python 3.9.18
@bp72
Copy link
Contributor

bp72 commented Dec 9, 2023

Hi @cedric-spinergie!

Could you please try one more thing to see if it helps?
Try to add src_paths parameter for each config to specify the source root for each project. https://pycqa.github.io/isort/docs/configuration/options.html#src-paths
For example:
scripts/pyproject.toml:

[tool.isort]
profile = "black"
line_length = 120
sections = "FUTURE,STDLIB,THIRDPARTY,FIRSTPARTY,LOCALFOLDER"
src_paths = ["scripts"]

and django/pyproject.toml

[tool.isort]
profile = "black"
line_length = 120
sections = "FUTURE,STDLIB,THIRDPARTY,FIRSTPARTY,LOCALFOLDER"
src_paths = ["django"]

I tried it in your example and it worked as expected with isort . --resolve-all-configs

@bp72
Copy link
Contributor

bp72 commented Feb 2, 2024

Hi @cedric-spinergie!
Have you had a chance to try this option?
And if there's still a problem, don't hesitate to reach out!

@sblask
Copy link

sblask commented Nov 8, 2024

I've got the same problem and the src_paths workaround worked for me, but it isn't great. The default behaviour is just counter intuitive and --resolve-all-configs makes it worse instead of fixing it. There seems to be a solution here: #2142 but it's a year old without any movement.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants