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 backports.entry_points_selectable for forward compatibility with importlib.metadata. - [closed] #1011

Closed
asottile opened this issue Apr 3, 2021 · 2 comments

Comments

@asottile
Copy link
Member

asottile commented Apr 3, 2021

In GitLab by @jaraco on Mar 30, 2021, 14:24

Merges feature/backports-entrypoints-select -> master

This MR builds on the attempt in !464 to update flake8 to rely on the new 'selectable' API for importlib metadata entry points. This change honors the request not to require bumping the requirement on importlib_metadata by building on the compatibility shim at backports.entry_points_selectable, building on lessons learned in python/importlib_metadata#298.

The compatibility shim promises to enable the preferred API even when the underlying importlib metadata API doesn't yet support it, allowing the use of importlib_metadata<3.6 and importlib.metadata on Python 3.8 and 3.9, but relying on the native APIs when available and avoiding the deprecations.

@asottile
Copy link
Member Author

asottile commented Apr 3, 2021

In GitLab by @asottile on Mar 30, 2021, 15:06

no sorry, I'd rather not introduce a new package on modern pythons as discussed before

@asottile
Copy link
Member Author

asottile commented Apr 3, 2021

In GitLab by @jaraco on Mar 30, 2021, 16:29

Hey Anthony. I really thought you'd be quite happy with this change. It avoids requiring a newer backport but bridges the gap between an API that I'd like to deprecate (as convenient as it seems at the moment) and a more flexible API. I've taken your feedback to heart and worked quite hard over the past month to come up with what I believe to be a low impact approach to make the transition. I really don't want to see flake8 users in the lurch when the deprecation (currently suppressed for flake8) becomes a breaking change. I respect that breaking changes are especially concerning and that's why I've invested a great deal of time in refining the approach and rolling it out carefully. Would you be willing to have a conversation about it - to see if we can overcome our differences?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant