Repository navigation
find_distributions breaks under python 3.8 #86
Description
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
Activity
jaraco commentedon Oct 22, 2020
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.metadatawhen available and fall back toimportlib_metadataon older Pythons.Does that address your issue or do we need to do more to paper over this transition?
jaraco commentedon Oct 22, 2020
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 commentedon Oct 22, 2020
In GitLab by @matejcik on Sep 10, 2019, 14:35
closed
jaraco commentedon Oct 22, 2020
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 commentedon Oct 22, 2020
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 commentedon Oct 22, 2020
In GitLab by @jaraco on Sep 10, 2019, 16:27
reopened
jaraco commentedon Oct 22, 2020
In GitLab by @webknjaz on Sep 10, 2019, 16:29
Ah, right. Same here: https://travis-ci.org/cherrypy/cheroot/jobs/583238931.
jaraco commentedon Oct 22, 2020
In GitLab by @asottile on Sep 10, 2019, 20:19
I've released pluggy 0.13.0 which should sidestep this issue
jaraco commentedon Oct 22, 2020
In GitLab by @webknjaz on Sep 10, 2019, 21:19
I confirm that the update fixes this issue.
jaraco commentedon Oct 22, 2020
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 commentedon Oct 22, 2020
In GitLab by @jaraco on Sep 11, 2019, 16:37
closed
jaraco commentedon Oct 22, 2020
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 commentedon Oct 22, 2020
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 commentedon Oct 22, 2020
In GitLab by @asottile on Sep 15, 2019, 20:44
I'd rather not depend on a provisional module until the release
jaraco commentedon Oct 22, 2020
In GitLab by @jaraco on Sep 16, 2019, 14:58
mentioned in commit c04c4b4
jaraco commentedon Oct 22, 2020
In GitLab by @jaraco on Sep 16, 2019, 14:58
mentioned in commit 06b8e26
jaraco commentedon Oct 22, 2020
In GitLab by @jaraco on Sep 16, 2019, 15:00
reopened
jaraco commentedon Oct 22, 2020
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 commentedon Oct 22, 2020
In GitLab by @jaraco on Sep 16, 2019, 15:54
mentioned in commit 08a3782
jaraco commentedon Oct 22, 2020
In GitLab by @jaraco on Sep 16, 2019, 15:54
closed via merge request !94
Move as_file to the global namespace and update documentation accordi…