Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rely on importlib_metadata 3.6 for nicer protocol. #732

Merged
merged 3 commits into from Feb 27, 2021

Conversation

@jaraco
Copy link
Member

@jaraco jaraco commented Feb 24, 2021

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).

@jaraco jaraco force-pushed the feature/importlib-metadata-entry-points-select branch 3 times, most recently from ee63c58 to a7c38f0 Feb 24, 2021
@jaraco jaraco force-pushed the feature/importlib-metadata-entry-points-select branch from a7c38f0 to 9424ff0 Feb 24, 2021
twine/cli.py Show resolved Hide resolved
Loading
Copy link
Contributor

@bhrutledge bhrutledge left a comment

Looks like a nice simplification. Anything else before merge?

Loading

@jaraco
Copy link
Member Author

@jaraco jaraco commented Feb 27, 2021

Looks like a nice simplification. Anything else before merge?

Nothing else. Merging.

Loading

@jaraco jaraco merged commit 22aaa04 into master Feb 27, 2021
41 of 42 checks passed
Loading
@jaraco jaraco deleted the feature/importlib-metadata-entry-points-select branch Feb 27, 2021
@stratakis
Copy link

@stratakis stratakis commented Mar 29, 2021

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?

Loading

@jaraco
Copy link
Member Author

@jaraco jaraco commented Mar 29, 2021

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.

Loading

@stratakis
Copy link

@stratakis stratakis commented Mar 31, 2021

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.

Loading

algitbot pushed a commit to alpinelinux/aports that referenced this issue Apr 13, 2021
This reverts commit dcff5dc.

This package was dropped earlier as it's functionality was integrated
into Python 3.8. However, it seems that newer versions of this package
still contains functionality not present in the Python standard library
at least until Python 3.10, and some packages (py3-keyring, py3-twine)
depend on that.

Read pypa/twine#732 (comment) for
context
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

4 participants