-
Couldn't load subscription status.
- Fork 7
Description
Hi! 👋
I package this project for Arch Linux. I would like to point out that the newly added dependency on importlib_resources is problematic/ not needed:
The importlib_resources project has been introduced to upstream the module as importlib.resources into cpython. This work has been completed with Python 3.7 (which has been released in 2018) and AFAIK the project now exists to add further features only.
That all being said: According to https://www.python.org/downloads/ the range of currently supported Python versions is 3.8 - 3.12 and I am wondering why #28 added a dependency on importlib_resources and not importlib.resources, which would not require to have another dependency at all. If anything downstream distributions want to get rid of importlib_resources and replace it with importlib.resources not the other way round!
Furthermore, I am wondering about the definition of requirements as is done here:
authentication-headers/setup.py
Lines 108 to 123 in 1e81143
| requires=[ | |
| "dkimpy>=0.7.1", | |
| "authres>=1.2.0", | |
| "publicsuffix2", | |
| "importlib_resources", | |
| "ipaddress", | |
| "dnspython" | |
| ] | |
| if sys.version_info >= (3, 3): | |
| requires=[ | |
| "dkimpy>=0.7.1", | |
| "authres>=1.2.0", | |
| "importlib_resources", | |
| "publicsuffix2", | |
| "dnspython" | |
| ] |
Why is this project targeting 3.3, a Python version that has been introduced in 2012 and EOL'ed in 2017? Relatedly, each requirement can be made to depend on a particular Python version! There is no need to specify them all again.
Closing:
For downstreams using importlib_resources has no benefit and it would be much preferred if importlib.resources was used.
Targeting EOL'ed Python versions without testing against them (or any of the newer ones) should be circumvented, as it introduces more and more workarounds etc. It is much cleaner and more straight forward to only target Python versions actually supported by the Python project!