Drop use of non-standard pkg_resources API

[dvarrazzo]

Use the canonical importlib.metadata.entry_points instead.

Fix #2404

[codecov]

Codecov Report

❌ Patch coverage is 83.33333% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 99.19%. Comparing base (0c8fc82) to head (be46cd4).
⚠️ Report is 4 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2405      +/-   ##
==========================================
+ Coverage   99.16%   99.19%   +0.03%     
==========================================
  Files          40       40              
  Lines        3101     3101              
  Branches      680      680              
==========================================
+ Hits         3075     3076       +1     
+ Misses         15       14       -1     
  Partials       11       11              

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[DanielNoord]

Thanks for the PR! Left some comments :)

[DanielNoord]

Can we keep these imports lazy like it was before?

[dvarrazzo]

To avoid adding an if every time there was an import pkg_resources I'd have a _pkg_resources internal module exposing entry_points.

What is the rationale?

[DanielNoord]

You could also do this with a cached function in this module that returns the import I think.

Originally somebody thought it better to make this lazy. I don't see a good reason for why we would want to change this so I'd prefer to keep it the same.

[dvarrazzo]

Well, when the code was importing from pkg_resources, which is a non-standard module teleported in Python virtualenv thanks to obscure forces, I can somewhat understand why the import was lazy: if it suddenly started failing (like now, in Python 3.14) I assume the thought was at least it won't fail for everyone on import but just for people who use this less used feature.

Now that the code is importing either a stdlib function or a function from a package marked as dependency, I don't see a good reason for failing.

AFAICS the package was first used in 2d76984, then some code following a similar pattern was added in b40e584, then again in 4cb72fa. I assume the code was copied over and modified, including the lazy-loading pattern. Maybe @timothycrosley might explain why those import are lazy?

Anyways, the last commit in this MR restores the lazy import behaviour. I don't think it is needed, especially if you have unit tests testing that the package works, but if you want it this way, it's there.

[DanielNoord]

@staticdev Could you review this as well? I'm wondering what you think of the lazy loading.

[staticdev]

I would actually remove support for python below 3.10., as 3.9 is pretty much eol: https://endoflife.date/python this actually will simplify the code and the Pr.
I think we can keep the lazy loading like it is right now.

[DanielNoord]

Seems like a lot more work to do proper clean up of 3.9? I'd say if this work we could at least just merge and release this and unblock 3.14 compatibility.

Afterwards we can worry about cleaning up for 3.9?

[rafaelcapucho]

I installed it using uv, as in uv tool install isort,

and when using with .isort.cfg, if I add profile = "black" it fails:

[settings]
profile = "black"
multi_line_output = 3
lines_between_types = 1
force_alphabetical_sort_within_sections = 1
Lexicographical = 1
group_by_package = 1

$ isort hdash/project/tasks.py

Traceback (most recent call last):
  File "/Users/kepler/.local/bin/isort", line 10, in <module>
    sys.exit(main())
             ~~~~^^
  File "/Users/kepler/.local/share/uv/tools/isort/lib/python3.13/site-packages/isort/main.py", line 1124, in main
    config = Config(**config_dict)
  File "/Users/kepler/.local/share/uv/tools/isort/lib/python3.13/site-packages/isort/settings.py", line 359, in __init__
    import pkg_resources
ModuleNotFoundError: No module named 'pkg_resources'

[DanielNoord]

@staticdev shall we just merge and release as is?

[dvarrazzo]

I have rebased this branch on master and fixed the lint job.

[staticdev]

That is fine, LGTM. Thanks @dvarrazzo and @DanielNoord