setup: move importlib_metadata to setup.cfg

[tmorrell]

❤️ Thank you for your contribution!

Description

Just having importlib_metadata in pyproject.toml doesn't install it for all use cases. It should be be in setup.cfg.

Checklist

Ticks in all boxes and 🟢 on all GitHub actions status checks are required to merge:

• I'm aware of the code of conduct.
• I've created logical separate commits and followed the commit message format.
• I've identified the copyright holder(s) and updated copyright headers for touched files (>15 lines contributions).
• I've NOT included third-party code (copy/pasted source code or new dependencies).
  • If you have added third-party code (copy/pasted or new dependencies), please reach out to an architect.

Reminder

By using GitHub, you have already agreed to the GitHub’s Terms of Service including that:

1. You license your contribution under the same terms as the current repository’s license.
2. You agree that you have the right to license your contribution under the current repository’s license.

[ntarocco]

this should not be needed if we have Python >= 3.9:

~/invenio/modules/idutils > python --version
Python 3.9.16
~/invenio/modules/idutils > python
Python 3.9.16 (main, Oct 12 2023, 17:53:07)
[Clang 15.0.0 (clang-1500.0.40.1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from importlib.metadata import entry_points
>>>

[utnapischtim]

but it is needed for python >= 3.12

[utnapischtim]

you are right. also for python >= 3.12 your line works. BUT the idutils is using importlib_metadata:

idutils/idutils/ext.py

Line 53 in 812f640

from importlib_metadata import entry_points

and not importlib.metadata

Python 3.12.7 (main, Oct  2 2024, 16:29:41) [GCC 12.2.1 20230304] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from importlib_metadata import entry_points
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ModuleNotFoundError: No module named 'importlib_metadata'
>>> 

[utnapischtim]

does this mean the better fix would be to change from importlib_metadata import entry_points to from importlib.metadata import entry_points the difference is _ vs .

[utnapischtim]

using importlib.metadata is possible for python3.9 because it has been added with python3.8: https://docs.python.org/3/library/importlib.metadata.html

[ntarocco]

I see that you have answered yourself 🤣

I asked @ptamarit if he could create a PR with:

• changing the imports to importlib.metadata
• changing the publish CI to use Python 3.9
• remove any install dependency of importlib
  and notify everyone, but @tmorrell was too fast :)

I believe the above should work and can be applied to other modules when touched/needed.

[tmorrell]

I tried importlib.metadata and it didn’t work exactly the same. That’s not to say it couldn’t be used…but it’s not a drop in replacement

[ntarocco]

I tried importlib.metadata and it didn’t work exactly the same. That’s not to say it couldn’t be used…but it’s not a drop in replacement

Yes you might be right. The same change was done here, and tested it.
Is it probably this one to apply?

[tmorrell]

That’s still using the dash version. I think it was an issue with the group parameter changing in importlib.metadata.

[ntarocco]

Checking the doc, the root cause of the issue is here:

Changed in version 3.12: The “selectable” entry points were introduced in importlib_metadata 3.6 and Python 3.10. Prior to those changes, entry_points accepted no parameters and always returned a dictionary of entry points, keyed by group. With importlib_metadata 5.0 and Python 3.12, entry_points always returns an EntryPoints object. See backports.entry_points_selectable for compatibility options.

They did quite a mess here :(

I created another PRs with your commits and a bit of extra: #110

[zzacharo]

We would need to implement locally in the module the mocking of entrypoints so that the tests will pass

[ntarocco]

superseeded by #110