find_distributions breaks under python 3.8

[jaraco]

In GitLab by @matejcik on Sep 10, 2019, 13:28

This seems to be a regression, as 0.20 works fine.

Python 3.8.0b4 (default, Sep  2 2019, 20:50:55) 
[GCC 7.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import importlib_metadata
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/matejcik/projekty/prace/trezor-firmware/python/.tox/py38/lib/python3.8/site-packages/importlib_metadata/__init__.py", line 527, in <module>
    __version__ = version(__name__)
  File "/home/matejcik/projekty/prace/trezor-firmware/python/.tox/py38/lib/python3.8/site-packages/importlib_metadata/__init__.py", line 494, in version
    return distribution(package).version
  File "/home/matejcik/projekty/prace/trezor-firmware/python/.tox/py38/lib/python3.8/site-packages/importlib_metadata/__init__.py", line 467, in distribution
    return Distribution.from_name(package)
  File "/home/matejcik/projekty/prace/trezor-firmware/python/.tox/py38/lib/python3.8/site-packages/importlib_metadata/__init__.py", line 181, in from_name
    dists = resolver(DistributionFinder.Context(name=name))
  File "<frozen importlib._bootstrap_external>", line 1385, in find_distributions
  File "/home/matejcik/projekty/prace/trezor-firmware/python/.tox/py38/lib/python3.8/re.py", line 275, in escape
    pattern = str(pattern, 'latin1')
TypeError: decoding to str: need a bytes-like object, Context found

[jaraco]

In GitLab by @jaraco on Sep 10, 2019, 14:22

Yes. It is a regression, and somewhat intentional. Thanks for reporting it.

The 0.21 release intentionally changed that interface... and the latest CPython 3.8 code is updated to be compatible, but previous beta releases are incompatible. You'll want to use importlib_metadata 0.20 for now... and importlib_metadata 0.21 on Python 3.8.0rc0 and later. Or even better, prefer importlib.metadata when available and fall back to importlib_metadata on older Pythons.

Does that address your issue or do we need to do more to paper over this transition?

[jaraco]

In GitLab by @matejcik on Sep 10, 2019, 14:35

I originally hit this because of pytest-dev/pluggy#222, which is fixed but unreleased. So we can close this.

[jaraco]

In GitLab by @matejcik on Sep 10, 2019, 14:35

closed

[jaraco]

In GitLab by @webknjaz on Sep 10, 2019, 15:51

FTR Travis' 3.8-dev is still hitting this: https://travis-ci.com/aio-libs/multidict/jobs/232751193#L260.

[jaraco]

In GitLab by @jaraco on Sep 10, 2019, 16:27

The commit to 3.8-dev landed only 1 hour ago. I expect if you're using nightly builds, the issue will go away following tonight's build.

This issue seems to be widespread enough that I'm tempted to create a bugfix release that will allow importlib_metadata (0.22) to accept (for some short period ending not too long after the rc1 release) the interface from importlib.metadata from Python 3.8 betas.

But given that these are betas, I'm going to hold out hope a little longer that it won't be necessary. So far, in the two examples we've examined, there's a suitable low-impact workaround and the problem is expected to resolve itself in fairly short order.

If there's a use-case for which it's difficult to implement a workaround and which won't resolve itself in 24 hours, then please report that here, and I'll use that as a signal to build a compatibility shim.

I'll leave this issue open for better visibility.

[jaraco]

In GitLab by @jaraco on Sep 10, 2019, 16:27

reopened

[jaraco]

In GitLab by @webknjaz on Sep 10, 2019, 16:29

Ah, right. Same here: https://travis-ci.org/cherrypy/cheroot/jobs/583238931.

[jaraco]

In GitLab by @asottile on Sep 10, 2019, 20:19

I've released pluggy 0.13.0 which should sidestep this issue

[jaraco]

In GitLab by @webknjaz on Sep 10, 2019, 21:19

I confirm that the update fixes this issue.

[jaraco]

In GitLab by @jaraco on Sep 11, 2019, 16:37

I think the impact of this issue has subsided. Do feel free to comment or re-open or open another issue if impact remains.

[jaraco]

In GitLab by @jaraco on Sep 11, 2019, 16:37

closed

[jaraco]

In GitLab by @asottile on Sep 15, 2019, 20:32

any way this could still be fixed for those of us not using nightly (for instance 3.8b4)?

[jaraco]

In GitLab by @jaraco on Sep 15, 2019, 20:39

It’s possible, maybe. What is the use case (using importlib_metadata 0.21 on Python 3.8b)? Have you considered giving preference to importlib.metadata over importlib_metadata? Would that be easier?

[jaraco]

In GitLab by @asottile on Sep 15, 2019, 20:44

I'd rather not depend on a provisional module until the release

[jaraco]

In GitLab by @jaraco on Sep 16, 2019, 14:58

mentioned in commit c04c4b4

[jaraco]

In GitLab by @jaraco on Sep 16, 2019, 14:58

mentioned in commit 06b8e26

[jaraco]

In GitLab by @jaraco on Sep 16, 2019, 15:00

reopened

[jaraco]

In GitLab by @jaraco on Sep 16, 2019, 15:06

In the aforementioned commits and !94, I'm proposing a compatibility shim that should avoid the reported issue. I've confirmed the fix by testing against CPython v3.8.0b4, where it fails before the patch and succeeds after. I don't intend to keep this compatibility shim long. @asottile, would you review please?

[jaraco]

In GitLab by @jaraco on Sep 16, 2019, 15:54

mentioned in commit 08a3782

[jaraco]

In GitLab by @jaraco on Sep 16, 2019, 15:54

closed via merge request !94