-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Implement isort's default-section
setting
#10149
Conversation
|
This will allow me to drop my dependency on |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is good work -- thanks @mmerickel!
I'll admit that I have some hesitancy to support this setting. I think it's possible to come up with a more intuitive and user-friendly configuration scheme for the use-case that motivated the change (e.g., if we want users to be able to merge standard library and third-party imports, perhaps we should focus on how to enable that?). At the same time, I understand why it's helpful to follow isort here.
default-section
setting
Thank you @charliermarsh! |
Thank you! Nice PR. |
## Summary This fixes astral-sh#7868. Support isort's `default-section` feature which allows any imports that match sections that are not in `section-order` to be mapped to a specifically named section. https://pycqa.github.io/isort/docs/configuration/options.html#default-section This has a few implications: - It is no longer required that all known sections are defined in `section-order`. - This is technically a bw-incompat change because currently if folks define custom groups, and do not define a `section-order`, the code used to add all known sections to `section-order` while emitting warnings. **However, when this happened, users would be seeing warnings so I do not think it should count as a bw-incompat change.** ## Test Plan - Added a new test. - Did not break any existing tests. Finally, I ran the following config against Pyramid's complex codebase that was previously using isort and this change worked there. ### pyramid's previous isort config https://github.com/Pylons/pyramid/blob/5f7e286b0629b0a5f1225fe51172cba77eb8fda1/pyproject.toml#L22-L37 ```toml [tool.isort] profile = "black" multi_line_output = 3 src_paths = ["src", "tests"] skip_glob = ["docs/*"] include_trailing_comma = true force_grid_wrap = false combine_as_imports = true line_length = 79 force_sort_within_sections = true no_lines_before = "THIRDPARTY" sections = "FUTURE,THIRDPARTY,FIRSTPARTY,LOCALFOLDER" default_section = "THIRDPARTY" known_first_party = "pyramid" ``` ### tested with ruff isort config ```toml [tool.ruff.lint.isort] case-sensitive = true combine-as-imports = true force-sort-within-sections = true section-order = [ "future", "third-party", "first-party", "local-folder", ] default-section = "third-party" known-first-party = [ "pyramid", ] ```
Summary
This fixes #7868.
Support isort's
default-section
feature which allows any imports that match sections that are not insection-order
to be mapped to a specifically named section.https://pycqa.github.io/isort/docs/configuration/options.html#default-section
This has a few implications:
section-order
.section-order
, the code used to add all known sections tosection-order
while emitting warnings. However, when this happened, users would be seeing warnings so I do not think it should count as a bw-incompat change.Test Plan
Finally, I ran the following config against Pyramid's complex codebase that was previously using isort and this change worked there.
pyramid's previous isort config
https://github.com/Pylons/pyramid/blob/5f7e286b0629b0a5f1225fe51172cba77eb8fda1/pyproject.toml#L22-L37
tested with ruff isort config