hooks: qt: fix compatibility with old PyQt5 (e.g., 5.9.2) #6114
Conversation
|
To me this raises the question of why on earth are we trying to access the |
I think that's a fallback in |
In what way? Edit: I've just remembered that your example breakage is on Conda - is this some conda specific quirk? |
This fix is targeting PyQt5 5.9.2 from conda main channel, where |
|
I don't suppose |
|
Actually, isn't Conda's PyQt5 just named |
Nope. And PyQt5 does not show up in |
The conda package is named just |
|
I've changed the commit description, the comment, and the news entry to reflect the fact that this is targeting PyQt5 5.9.2 from conda main channel. The old PyQt5 5.9.x wheels from PyPI seem to contain dist information, and would likely not trigger this issue. |
|
Will merge after reformat, though. |
PyQt5 5.9.2 from conda's main channel lacks dist information, which forces the is_module_satisfies() call to take a fallback path that checks for __version__ module attribute. This attribute does not exist, causing the whole version check to result in an AttributeError. Handle such error gracefully, as it means that the installed PyQt5 version is definitely still using the old PyQt5/Qt layout.
bwoodsend
added
the
merge-on-ci-pass
…#6114) PyQt5 5.9.2 from conda's main channel lacks dist information, which forces the is_module_satisfies() call to take a fallback path that checks for __version__ module attribute. This attribute does not exist, causing the whole version check to result in an AttributeError. Handle such error gracefully, as it means that the installed PyQt5 version is definitely still using the old PyQt5/Qt layout.
Older versions of
PyQt5(e.g., 5.9.2 fromconda's main channel) lack__version__attribute, causingis_module_satisfies()call to fail withAttributeError. Therefore, encountering this error means that the installedPyQt5version is definitely still using the oldPyQt5/Qtlayout.