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

add force-alphabetical-sort-within-sections flag to isort settings #4670

Open
Tracked by #6190
alexdauenhauer opened this issue May 26, 2023 · 17 comments
Open
Tracked by #6190
Labels
configuration Related to settings and configuration isort Related to import sorting

Comments

@alexdauenhauer
Copy link

alexdauenhauer commented May 26, 2023

While I personally like isort better, my company uses reorder-python-imports so I am wondering if there is already support for this and I missed it in the docs, or if support could be added? I am loving this package and would love to have it auto-run the import sorting in the format I need.

Actually I think it is better to just add force-alphabetical-sort-within-sections flag to isort settings

@alexdauenhauer
Copy link
Author

actually it turns out I can almost achieve the same functionality, but the isort arg that I need is force-alphabetical-sort-within-sections and ruff does not yet support this

@JonathanPlasse
Copy link
Contributor

Can you share the configuration?
A profile reporder-python-imports could be added.

@alexdauenhauer
Copy link
Author

alexdauenhauer commented May 26, 2023

well now I think what would actually be better than adding support for reorder-python-imports, would be to just add the force-alphabetical-sort-within-sections flag for available isort args. I think isort can do everything that reorder-python-imports can do, but not all the flags for isort are available to enable that functionality

@alexdauenhauer alexdauenhauer changed the title Support for reorder-python-imports add force-alphabetical-sort-within-sections flag to isort settings May 26, 2023
@charliermarsh charliermarsh added isort Related to import sorting configuration Related to settings and configuration labels May 26, 2023
@sanmai-NL
Copy link

@alexdauenhauer
Copy link
Author

@sanmai-NL unfortunately not. The sorting rules are slightly different. sort-within-sections prioritizes case over alphanumeric (e.g. MY_CONSTANT will be sorted on top of alphabetical_method)

@perezzini
Copy link

Any updates about this? Thanks!

@owenlamont
Copy link
Contributor

I'd like this too, I'm trying to get Ruff adopted where I work but this is one area where a lot of code gets formatted differently to our current isort configuration.

@owenlamont
Copy link
Contributor

Update: Actually I don't think this is an issue anymore. Once I noticed the case-sensitive argument which I set to false and I fixed and tweaked some other ruff configuration I was able to exactly reproduce my old isort configuration sorting behaviour that had force_alphabetical_sort_within_sections set to true.

@Pierre-Sassoulas
Copy link
Contributor

@owenlamont do you mind sharing your configuration to mimic force_alphabetical_sort_within_sections, please ? I didn't manage to recreate it from the description.

Pierre-Sassoulas added a commit to Pierre-Sassoulas/pytest that referenced this issue Jan 31, 2024
If we want to keep parity with reorder-python-imports,

we need astral-sh/ruff#4670
@owenlamont
Copy link
Contributor

Hi @Pierre-Sassoulas - this was my Ruff isort config taken from my pyproject.toml (note I excluded known-first-party and known-third-party modules which will be specific to your repo). This sorting was close to but not quite identical to isort. I think there were some minor differences with Ruff sorting on full relative import paths (which I personally liked) - I think the difference was something like that - I don't exactly remember but most of the time the import sort order came out identical to how we had isort configured.

[tool.ruff.isort]
case-sensitive = false
combine-as-imports = true
force-sort-within-sections = true
known-first-party = []
known-third-party = []
lines-after-imports = 2
order-by-type = false
section-order = [
    "future",
    "standard-library",
    "third-party",
    "first-party",
    "local-folder"
]

This closely matched the behaviour of the old isort config:

[tool.isort]
profile = "black"
multi_line_output = 3
force_sort_within_sections = true
force_alphabetical_sort_within_sections = true
sections = ["FUTURE", "STDLIB", "THIRDPARTY", "FIRSTPARTY", "LOCALFOLDER"]
known_first_party = []
known_thirdparty = []
skip_gitignore=true
lines_after_imports=2
combine_as_imports=true

@Pierre-Sassoulas
Copy link
Contributor

It's working, thank you a lot @owenlamont !

The sorting rules are slightly different. sort-within-sections prioritizes case over alphanumeric (e.g. MY_CONSTANT will be sorted on top of alphabetical_method)

The specific option that fix this is order-by-type = false.

I guess the issue can be closed then.

Pierre-Sassoulas added a commit to Pierre-Sassoulas/pytest that referenced this issue Feb 2, 2024
…e, to ruff

ruff is faster and handle everything we had prior.

isort configuration done based on the indication from
astral-sh/ruff#4670, previousely based on
reorder-python-import (pytest-dev#11896)

flake8-docstrings was a wrapper around pydocstyle (now archived) that
explicitly asks to use ruff in PyCQA/pydocstyle#658.

flake8-typing-import is useful mainly for project that support python 3.7
and the one useful check will be implemented in astral-sh/ruff#2302

We need to keep blacken-doc because ruff does not handle detection
of python code inside .md and .rst. The direct link to the repo is
now used to avoid a redirection.

Manual fixes:
- Lines that became too long
- % formatting that was not done automatically
- type: ignore that were moved around
- noqa of hard to fix issues (UP031 generally)
- fmt: off and fmt: on that is not really identical
  between black and ruff
- autofix re-order in pre-commit from faster to slower

Co-authored-by: Ran Benita <ran@unusedvar.com>
Pierre-Sassoulas added a commit to Pierre-Sassoulas/pytest that referenced this issue Feb 2, 2024
…e, to ruff

ruff is faster and handle everything we had prior.

isort configuration done based on the indication from
astral-sh/ruff#4670, previousely based on
reorder-python-import (pytest-dev#11896)

flake8-docstrings was a wrapper around pydocstyle (now archived) that
explicitly asks to use ruff in PyCQA/pydocstyle#658.

flake8-typing-import is useful mainly for project that support python 3.7
and the one useful check will be implemented in astral-sh/ruff#2302

We need to keep blacken-doc because ruff does not handle detection
of python code inside .md and .rst. The direct link to the repo is
now used to avoid a redirection.

Manual fixes:
- Lines that became too long
- % formatting that was not done automatically
- type: ignore that were moved around
- noqa of hard to fix issues (UP031 generally)
- fmt: off and fmt: on that is not really identical
  between black and ruff
- autofix re-order in pre-commit from faster to slower

Co-authored-by: Ran Benita <ran@unusedvar.com>
Pierre-Sassoulas added a commit to pytest-dev/pytest that referenced this issue Feb 2, 2024
…e, to ruff (#11911)

ruff is faster and handle everything we had prior.

isort configuration done based on the indication from
astral-sh/ruff#4670, previousely based on
reorder-python-import (#11896)

flake8-docstrings was a wrapper around pydocstyle (now archived) that
explicitly asks to use ruff in PyCQA/pydocstyle#658.

flake8-typing-import is useful mainly for project that support python 3.7
and the one useful check will be implemented in astral-sh/ruff#2302

We need to keep blacken-doc because ruff does not handle detection
of python code inside .md and .rst. The direct link to the repo is
now used to avoid a redirection.

Manual fixes:
- Lines that became too long
- % formatting that was not done automatically
- type: ignore that were moved around
- noqa of hard to fix issues (UP031 generally)
- fmt: off and fmt: on that is not really identical
  between black and ruff
- autofix re-order in pre-commit from faster to slower

Co-authored-by: Ran Benita <ran@unusedvar.com>
@Jari27
Copy link

Jari27 commented Mar 6, 2024

I have a similar problem that I cannot seem to solve with the current settings on v0.2.1 (although I cannot find anything in the changelogs that indicate this was solved in v0.2.2 or v0.3.0).

I have the following 5 imports:

from pyspark.sql import Column, DataFrame
from pyspark.sql import functions as F
from pyspark.sql import SparkSession
from pyspark.sql import types as T

These are sorted by isort with the following config:

[tool.isort]
line_length = 120
multi_line_output = 3
force_alphabetical_sort_within_sections = "True"
force_sort_within_sections = "False"
profile = "black"

I cannot seem to get the same behaviour with ruff, as it always combines the first and third line into this:

from pyspark.sql import Column, DataFrame, SparkSession
from pyspark.sql import functions as F
from pyspark.sql import types as T

with the following config:

[tool.ruff.lint.isort]
force-sort-within-sections = false
order-by-type = false
case-sensitive = false

Am I misconfiguring anything? It seems like the alphabetical sort is sorting AFTER grouping, instead of before. And I cannot seem to turn this off.

@samdoran
Copy link

@Jari27 I think you want force-single-line = true.

from pyspark.sql import Column
from pyspark.sql import DataFrame
from pyspark.sql import functions as F
from pyspark.sql import SparkSession
from pyspark.sql import types as T

@Jari27
Copy link

Jari27 commented Apr 26, 2024

@samdoran Thanks, that is a lot closer but still not fully compatible. isort (isort==5.10.1) instead puts Column and DataFrame on the same line.

@charliermarsh
Copy link
Member

Yes we don't support that.

@charliermarsh
Copy link
Member

It's intentional and documented here: https://docs.astral.sh/ruff/faq/#how-does-ruffs-import-sorting-compare-to-isort

@Jari27
Copy link

Jari27 commented Apr 28, 2024

Ah that's fair. Not sure how I missed it! Thanks for the help!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
configuration Related to settings and configuration isort Related to import sorting
Projects
None yet
Development

No branches or pull requests

9 participants