Import sorting does not (immediately) converge?

[ax3l]

Hi,

I am using ruff verison 0.5.6 in pyAMReX (linter, not the formatter).

I am using pre-commit to update our source code after merge to development. I used black in the past and switched this week, discovering on August 10th and following that ruff creates a lot of rotating changes when run multiple times:
AMReX-Codes/pyamrex@74e0762
AMReX-Codes/pyamrex@5dc9c02
AMReX-Codes/pyamrex@902c41b
...
https://github.com/AMReX-Codes/pyamrex/commits/development/

for code of the form

from a.b1 import c1
from a.b1 import c1 as cc1
from a.b2 import c2
from a.b3 import c3

Is there a way to avoid this?

This happens for us on .pyi headers and we intentionally have an alias for some of those imports (for backwards compatibility with a public API change that we are shipping).

[charliermarsh]

I can take a look.

[charliermarsh]

It's possible that we've just never seen this pattern before and so the sort isn't stable:

from amrex.space1d.amrex_1d_pybind import IntVect1D
from amrex.space1d.amrex_1d_pybind import IntVect1D as IntVect

[ax3l]

Thank you for taking a look. Yes, an unstable isort pattern seems to cause this. I recently switched over to all-ruffing from isort+black+...

The pattern here is for backwards compatibility as we face out the `IntVect` type for more explicit versions in our public APIs. Technically, the file that shows this is autogenerated from [pybind11-stubgen](https://github.com/sizmailov/pybind11-stubgen). This is the line we do to declare the alias: https://github.com/AMReX-Codes/pyamrex/blob/c61add4fd44ad4ec69b131865375d76c68f12b29/src/Base/IntVect.cpp#L185

[charliermarsh]

Did you have any sort of configuration set? Like:

[tool.ruff.lint.isort]
force-single-line = true

The style in those files doesn't match our standard style, so trying to figure out how to reproduce.

[ax3l]

No, none of that kind set. I now add "amrex" as known first party module, but that's all I set (no change with or without that option regarding the stability issue).

I just realized I rebaded out the unstable sort commits yesterday in my mainline (using isort again for a stable sort), please let me know if I shall add those again in a feature branch.

[charliermarsh]

Okay thanks. I'm just struggling because if I check out 858e2a9359c6379782b3f2766e5415ba61be44f2 and run ruff check --select I --fix, it completely changes the import style in those files, so I don't think Ruff was run on those commits. Am I misunderstanding?

[ax3l]

That is right, this is the commit just right before I switched from black+isort to ruff.

Here is how I see the issue:

1. I build and install the project.
2. I run pybind-stubgen via this script to update (recreate) the .pyi files in the repo
3. I run the ruff linter

The last two steps repeated create the unstable result for these imports.

(Automated via pre-commit rules - I just added isort again at the end for stability - in this workflow)

[ax3l]

Example file after step 1 & 2: src/amrex/space3d/__init__.pyi

After running ruff check --select I --fix v0.5.7: src/amrex/space3d/__init__.pyi

[ax3l]

This is super interesting, the local files I create differ from the commits I autogenerated with pre-commit above (only difference I know is that they used ruff 0.5.6).
Maybe because I actually run all of E,F,I?

[ax3l]

Oh no, I think I see the issue, it's the pre commit.

Either I should list no types or include explicitly pyi
https://github.com/AMReX-Codes/pyamrex/blob/c61add4fd44ad4ec69b131865375d76c68f12b29/.pre-commit-config.yaml#L82

[ax3l]

I think it was indeed the case that in the pre-commit rules, the .pyi files were not sorted at all, resulting in the unstable result of pybind11-stubgen to fluctuate.
AMReX-Codes/pyamrex#356

The underlying issue is that I did not know what to put in types_or, which comes from pre-commit itself, but I only looked at the ruff docs:
https://github.com/astral-sh/ruff-pre-commit?tab=readme-ov-file#using-ruff-with-pre-commit
https://pre-commit.com/#filtering-files-with-types

I am so sorry for the confusion and noise.