Dropping isort and move to lint.isort rule in ruff

[tkoyama010]

Overview

Dropping isort and moving to lint.isort rule in ruff.

Close #6137

Details

• See https://docs.astral.sh/ruff/rules/#isort-i.

[tkoyama010]

pre-commit.ci autofix

[codecov]

Codecov Report

Attention: Patch coverage is 99.26618% with 11 lines in your changes are missing coverage. Please review.

Project coverage is 97.08%. Comparing base (7841b34) to head (9ba41d6).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5712      +/-   ##
==========================================
+ Coverage   96.99%   97.08%   +0.08%     
==========================================
  Files         141      141              
  Lines       24669    25935    +1266     
==========================================
+ Hits        23928    25179    +1251     
- Misses        741      756      +15     

[user27182]

I'm not sure how much overlap this tool has with isort, but this seems worth considering :

https://github.com/asottile/reorder-python-imports

Its main goal is to reduce merge conflicts.

[user27182]

I'm not sure how much overlap this tool has with isort, but this seems worth considering :

https://github.com/asottile/reorder-python-imports

Its main goal is to reduce merge conflicts.

For context, I stumbled upon reorder-python-imports trying to look for a solution to #5621 (comment) . In this case, reorder-python-imports could be used to automatically add from future import __annotations__ to every file in the code base to support the type aliases for the docs. The config would be similar to this: https://github.com/asottile/pyupgrade/blob/df17dfa3911b81b4a27190b0eea5b1debc7ffa0a/.pre-commit-config.yaml#L18-L20

I plan on opening a new PR with reorder-python-imports to support this. And so if this works and the PR is accepted, then perhaps we may want to also use reorder-python-imports instead of isort. Just an idea though, I am not very familiar with these linting tools.

[tkoyama010]

Just an idea though, I am not very familiar with these linting tools.

No problem. We will review it.

[user27182]

I'm not sure how much overlap this tool has with isort, but this seems worth considering :
https://github.com/asottile/reorder-python-imports
Its main goal is to reduce merge conflicts.

For context, I stumbled upon reorder-python-imports trying to look for a solution to #5621 (comment) . In this case, reorder-python-imports could be used to automatically add from future import __annotations__ to every file in the code base to support the type aliases for the docs. The config would be similar to this: https://github.com/asottile/pyupgrade/blob/df17dfa3911b81b4a27190b0eea5b1debc7ffa0a/.pre-commit-config.yaml#L18-L20

I plan on opening a new PR with reorder-python-imports to support this. And so if this works and the PR is accepted, then perhaps we may want to also use reorder-python-imports instead of isort. Just an idea though, I am not very familiar with these linting tools.

I looked into using reorder-python-imports. It is fundamentally incompatible with black (black adds a new line after docstrings, reorder-python-imports insists on removing it), see summary about this issue here: psf/black#4175 (comment)

The main goal of my earlier suggestion was to add from __future__ import annotations to every file. This can be accomplished with ruff and the proposed changes from this PR by adding this option:

[tool.ruff.lint.isort]
required-imports = ["from __future__ import annotations"]

As an aside, in case there is a desire to reduce merge conflicts (which is another reason to use reorder-python-imports), the force-single-line option may also be used.

So, there is no need to make use of reorder-python-imports as a pre-commit hook.

+1 for this PR and dropping isort and using ruff instead.

[tkoyama010]

pre-commit.ci autofix

[tkoyama010]

pre-commit.ci autofix

[tkoyama010]

pre-commit.ci autofix

[user27182]

The documentation build for 1fc8cfc took about 2h20 mins. Usually it's about 1h10 mins. Not sure how the caching works for the build, maybe it took extra long because pretty much every file in the repo got modified, so had to be completely re-built from scratch? Hopefully it's not a permanent increase in build time.

[tkoyama010]

The documentation build for 1fc8cfc took about 2h20 mins. Usually it's about 1h10 mins. Not sure how the caching works for the build, maybe it took extra long because pretty much every file in the repo got modified, so had to be completely re-built from scratch? Hopefully it's not a permanent increase in build time.

The cause is that the directory under the examples directory was rerun. After the merge, a new cache will be created and we expect the execution time to return to normal.