Regression in Ruff's ordering of import aliases with force-sort-within-sections

[cmsetzer]

It looks like #7963 introduced a regression in Ruff's ordering of certain import aliases when force-sort-within-sections is enabled. In version 0.1.3 and prior, Ruff and isort produced identical output under this setting.

Example

• Ruff version 0.1.5
• isort version 5.12.0

Given pyproject.toml:

[tool.isort]
force_sort_within_sections = true

[tool.ruff.isort]
force-sort-within-sections = true

And example.py:

import encodings
from datetime import timezone as tz
from datetime import timedelta
import datetime as dt
import datetime

isort produces the following:

$ cat example.py | isort -

import datetime
import datetime as dt
from datetime import timedelta
from datetime import timezone as tz
import encodings

...while Ruff now places import datetime as dt out of order:

$ cat example.py | ruff check --fix --no-cache --select="I001" --stdin-filename="-"

import datetime
from datetime import timedelta
from datetime import timezone as tz
import datetime as dt
import encodings

Found 1 error (1 fixed, 0 remaining).

[charliermarsh]

Thanks! @bluthej, are you able to take a look at this? If not, I understand and can investigate myself, but thought I would ask first since it's likely related to your recent refactor.

[charliermarsh]

Regardless, @cmsetzer, will make sure this is fixed for the next release. Thanks for the clear write-up.

[bluthej]

@charliermarsh sure I'll take a look at it!

[charliermarsh]

@bluthej - Thank you!

[bluthej]

Ok so what happens is the from imports don't have an "asname", so they have a None that places them before the import ... as.

Looks like inverting the last two fields of ModuleKey fixes it, and all the tests pass, but before submitting a PR I'd like to look at the code before my refactor to make sure that this is how the ordering took place.