Repository navigation
3.10b2 -> 3.10b3 regression in importlib.metadata for rinoh #88625
Description
| BPO | 44459 |
|---|---|
| Nosy | @jaraco, @asottile, @pablogsal |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = 'https://github.com/jaraco'
closed_at = <Date 2021-06-19.23:43:36.535>
created_at = <Date 2021-06-19.06:22:26.381>
labels = ['deferred-blocker', 'library', '3.10', 'type-crash']
title = '3.10b2 -> 3.10b3 regression in importlib.metadata for rinoh'
updated_at = <Date 2021-06-19.23:43:36.532>
user = 'https://github.com/asottile'bugs.python.org fields:
activity = <Date 2021-06-19.23:43:36.532>
actor = 'jaraco'
assignee = 'jaraco'
closed = True
closed_date = <Date 2021-06-19.23:43:36.535>
closer = 'jaraco'
components = ['Library (Lib)']
creation = <Date 2021-06-19.06:22:26.381>
creator = 'Anthony Sottile'
dependencies = []
files = []
hgrepos = []
issue_num = 44459
keywords = ['3.10regression']
message_count = 6.0
messages = ['396117', '396137', '396139', '396141', '396146', '396154']
nosy_count = 3.0
nosy_names = ['jaraco', 'Anthony Sottile', 'pablogsal']
pr_nums = []
priority = 'deferred blocker'
resolution = 'wont fix'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'crash'
url = 'https://bugs.python.org/issue44459'
versions = ['Python 3.10']
Activity
asottile commentedon Jun 19, 2021
installed from git:
working in 3.10 b2:
broken in 3.10 b3:
jaraco commentedon Jun 19, 2021
I suspect the performance enhancements to distribution deduplication are relevant here. Previously, distributions were deduplicated based on the canonical distribution name. Now they're deduplicated on the normalized name. And it seems that when attempting to calculate the normalized name in the indicated environment that the Distribution.name isn't a text string. That's a little surprising, but I'll investigate to see how that condition comes about.
jaraco commentedon Jun 19, 2021
Running the debugger, I can confirm that Distribution.name is None in this case:
jaraco commentedon Jun 19, 2021
It seems that even on Python 3.9 or 3.10b2, the DynamicRinohDistribution would return
Nonefor thenameproperty (despite the attempt to return the empty string). The Python object model doesn't allow overriding descriptor (@Property) in a superclass with a static class property in the subclass.I'm struggling to understand how the DynamicRinohDistribution works at all. I think I see.
importlib.metadata.Distribution, while it declares a couple of abstract methods, doesn't actually declare itself an abstract base class, so someone can subclass it and get the degenerate behavior for the abstract methods. That's why a DynamicRinohDistribution.metadata getsNoneforself.read_textand thenemail.message_from_string(None)returns an emptyMessageobject.My instinct here is that the
Distribution.namewas always expected to return a string and the fact that it's returningNoneis a symptom of the subclass not implementing the abstract methods. To be sure, type annotations might have helped here (if thenameproperty declared that the return type isstr, thenNonewould be an invalid return value).The importlib distribution discovery mechanism was designed for other package distribution providers to make their distributions visible. It was not designed with the Rinoh use-case in mind (where a distribution already installed using the standard finders would present other "dynamic" distributions).
Given that Rinoh is using the distribution discovery mechanism in a way that it was not designed to support and is unlikely to be a widespread (or even repeated) use-case, I'm leaning toward a recommendation that the issue be fixed in Rinoh by defining a name property that returns text (and preferably something other than the empty string).
jaraco commentedon Jun 19, 2021
A small patch to rinoh seems to work around the issue:
Anthony, does that recommendation address the concern? Do you have any reason to think other users may be doing something similarly? Do you think it's worth adding a compatibility shim to support this improper usage?
jaraco commentedon Jun 19, 2021
I submitted brechtm/rinohtype#270 to address the issue in rinohtype. Please feel free to reopen and address the questions posed above if appropriate.
BobDenny commentedon Apr 16, 2022
@jaraco -- I hand-applied this tiny patch to my resource.py from rinoh 0.5.3 (2021-06-16) and I now have a functional rinoh. Thank you so much. This exact issue "out of the box:" got me too and I'm using 3.7.
Python 3.7.8 (tags/v3.7.8:4b47a5b6ba, Jun 28 2020, 08:53:46) [MSC v.1916 64 bit (AMD64)] on win32