Rely on importlib_metadata 3.6 for nicer protocol.

[jaraco]

Following up on #728, I've spent some time on importlib_metadata working out a new interface that's a lot more amenable to the various use-cases, including this one. As you can see, this new interface creates a much more straightforward usage for Twine.

This change does expand the scope of Python versions that require importlib_metadata but it's expected these changes will become available in future Python versions (likely 3.10).

[bhrutledge]

Looks like a nice simplification. Anything else before merge?

[jaraco]

Looks like a nice simplification. Anything else before merge?

Nothing else. Merging.

[stratakis]

This change blocks us from updating to the latest twine version on Fedora unfortunately. Since no packages were relying anymore on the external importilib_metadata we went ahead and removed the package from the distribution as we expected everything to rely on the stdlib. Also noting here that the oldest supported Fedora version has Python 3.8 as its main system interpreter so we'll have the module always available.

Are there features in the importlib_metadata that do not exist in the stdlib module?

[jaraco]

tl;dr: Yes, any feature from importlib_metadata 1.6 and later.

I'm afraid this change isn't the only one that's going to require importlib_metadata > 3.6. For instance, keyring also adopted this change. More importantly, importlib_metadata 3.9 deprecates the older behavior, incentivizing users to update to the newer entry_points API only available in Python 3.10. Additionally, there are features and performance improvements in importlib_metadata 3.7-3.9 (also landed or likely to land in Python 3.10) that are not available in importlib.metadata as found on Python 3.8 and 3.9. And best I can tell, importlib_metadata 1.5 is the last version merged into CPython 3.8 and 3.9), so any library that seeks improvements introduced in importlib_metadata 1.6+ would require importlib_metadata even if on Python 3.8.

So there's a decent demand for the third-party module and the demand is expected to become strong with the API change for entry_points, slated for a backward-incompatible API change (such as implemented in this PR). This backport and forward port provides a bridge between the current behavior and the behavior anticipated for importlib_metadata 4.0 and Python 3.11 (actual versions may vary), so other libraries are likely to opt in to the features but retain compatibility with older Pythons through use of importlib_metadata.

I hope that clarifies the need to honor any package's dependency declarations (not just twine here). If that transition is causing consternation, please consider filing an issue with importlib_metadata. I'd be happy to help explain the motivations or clarify the situation.

[stratakis]

Your explanation has been thorough and quite detailed thanks a lot for that! In that case the sane thing to do would be to re-introduce the package on Fedora.