-
-
Notifications
You must be signed in to change notification settings - Fork 157
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
Please revert importlib_metadata improvements. #503
Comments
That extra dependency will become optional again in Python 3.10 alpha 7. Keyring is attempting to use the new, cleaner interface for entry points afforded by importlib_metadata 3.6 and to avoid the deprecation of the prior interface. See python/importlib_metadata#284 for motivation for this change. I'd like for hypothesis to make a similar change. In a future version, I plan to deprecate the dict-like behavior and eventually remove it (probably in importlib_metadata 4.x and Python 3.11). I'd like to recommend that Hypothesis model after what keyring has done here. I think you'll find it's a nicer interface for Hypothesis as well. I'd be happy to help draft the change to enable that behavior, but I'd not presume to do if bumping a dependency (and expanding the number of Python versions on which the backport is necessary) is something your project would wish to avoid. Can you explain why having an added dependency is a problem? |
Ah, nice! That's going to be awesome for everyone who uses it 😁
Adding a dev-time dependency via Adding a runtime dependency for Hypothesis is a somewhat bigger deal, because we have some fairly weird usecases (development versions of CPython and PyPy, unusual Linux distros, etc.) where Python-version-specific dependencies can be pretty painful to set up and we want everyone to keep upgrading to the latest versions of Hypothesis even on old platforms (until EOL). This is taken far enough that our entry-points logic falls back through To be clear I'm entirely in favor of the new API and wouldn't suggest a slower deprecation cycle; I'm just in the habit of going to unreasonable lengths with compatiblity layers 😅 |
@Zac-HD Please also have a look at backports.entry_points_selectable, which handles the fall back as long as you can depend on it (and its dependency on Let me know if there's anything more you think I can do here. |
All good I think - from HypothesisWorks/hypothesis#2947 we'll try the new version, and just fall back to the older API if it doesn't work. |
Could it be marked as required only for Python < 3.10 in |
Based on the failing CI for #502, I think we're just asking for 473465e to be reverted... it's a nicer interface for the implementation of
keyring
, but as a consumer of the code I'd prefer to avoid the extra dependency 😕Originally posted by @Zac-HD in #499 (comment)
The text was updated successfully, but these errors were encountered: