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

Documentation for what conditions are needed to detect each module type #1932

Open
jack89roberts opened this issue May 11, 2022 · 0 comments

Comments

@jack89roberts
Copy link

Firstly thanks for isort, I've incorporated it into my projects recently and it's great!

I've noticed some subtleties in how imports are classified, particularly for imports that should be treated as first-party but may be picked up as third-party depending on the working directory and configuration (e.g. #1497).

I'd find it really helpful if the documentation had a "cheat sheet" on the rules/conditions that lead to an import being classified as FUTURE / STDLIB / THIRDPARTY / FIRSTPARTY / LOCALFOLDER (especially first party as mentioned), and if relevant how these can be configured (e.g. with known first-party or similar). Apologies if this already exists but I've struggled to find it.

The specific case that's left me scratching my head is running isort --verbose --check-only broken.py from this directory in this repo detects mypackage as third-party rather than first-party. However, if I set up a simple example elsewhere then it seems to get correctly identified as first-party as long as isort is run in the same directory. So I think there's something about the config/file structure of that linked repo which causes a different result.

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

1 participant