Use the stdlib importlib.metadata when available

[eli-schwartz]

The use of importlib_metadata relies on features that were introduced in python 3.10. Aside for that, it should be fine to use the stdlib directly.

Fixes #773

From #773 (comment):

I think this should at least wait until 3.10 is officially released and is added to Twine's testing matrix.

It's in the testing matrix. More importantly, we are now up to python 3.12 -- there are more versions of non-EOL python that have a suitable stdlib version than don't.

If we do decide to use importlib.metadata, then I think the version check should be done in one place, as suggested in #772 (comment).

I'm not sure I understand, largely because no specific reason was given there. Adding a new module just to wrap one import seems like a very complicated solution for something that doesn't need continual maintenance, and introduces additional stat'ing of the filesystem / opening a bunch more files for reading, to boot. If the concern is about dropping outdated version blocks in just one place, then puypgrade (as previously used in this repo) can make that edit for you. :)

[jaraco]

This looks fine to me. importlib_metadata 3.6 was included in Python 3.10, so it's unlikely that twine is reliant on features added in later Pythons or releases of importlib_metadata, and the tests seem to confirm that.

[eli-schwartz]

The refreshed CI has two issues resulting in failures:

• tests pass but reduce coverage by 1%? 🤷
• integration failure because of setuptools changes in canonicalization of sdist/wheel filenames.

The coverage thing is interesting because if you could collect coverage data across multiple CI jobs and analyze them together, I bet it would not fail. It's just failing because version-dependent code branches. I know that external services can aggregate coverage data across CI runs (even more useful when you have OS-specific branches!) but I'm unfamiliar with the available options for local analysis inside the action. Maybe copying coverage data to an artifact and analyzing it in a later job?

[jaraco]

My vote is to ignore the coverage concerns or exclude them. I hope eventually to learn how to collect the coverage results together, but I haven't yet done so and when I do, I'll do that in jaraco/skeleton and/or coherent-oss and not for one project at a time.

[eli-schwartz]

Great, works for me. :) I wasn't going to have time to look into that either way.

[sigmavirus24]

Actually there's a blog post from Hynek that makes lays out how to do this well. It's not hard

[jaraco]

It seems like fixing the coverage strategy is out of scope for the proposed change and is already tracked in #954.

[jaraco]

CI is broken pending the merge of #1123.

[jaraco]

CI is broken pending the merge of #1123.

The 5.1.1 release has a workaround for the pkginfo error.

[jaraco]

In the latest commit, I've consolidated the compatibility logic into its own module, a module that clearly indicates its candidacy for removal after Python 3.9 is dropped.

[jaraco]

Now the tests are failing with twine/__init__.py:48: error: Module has no attribute "parseaddr" [attr-defined]. But this diff doesn't alter that behavior.

Hmm. It seems to be an error in mypy. Changing the import to import email.utils works around the glitch.