Please revert importlib_metadata improvements.

[jaraco]

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)

[jaraco]

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?

[Zac-HD]

Ah, nice! That's going to be awesome for everyone who uses it 😁

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?

Adding a dev-time dependency via keyring is no problem at all; initially I thought that it was just missing some conditional logic but obviously that's not the case.

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 importlib.metadata, then importlib_metadata, and then pkg_resources, and finally just skip loading plugins with a warning - and I'll cheerfully add the new API to the front of that list!

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 😅

[jaraco]

@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 importlib_metadata for Python older than 3.8). It sounds like it won't help you if you need to fall back to pkg_resources, but you may want to consider it.

Let me know if there's anything more you think I can do here.

[Zac-HD]

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.

[dotlambda]

That extra dependency will become optional again in Python 3.10 alpha 7.

Could it be marked as required only for Python < 3.10 in setup.cfg?