The org.kde.Platform flatpak runtime doesn't include PyQt5. This makes packaging python applications using it somewhat inconvenient, as it involves building PyQt5 and bundling it with the application.
(In reply to Carles from comment #0) > The org.kde.Platform flatpak runtime doesn't include PyQt5. This makes > packaging python applications using it somewhat inconvenient, as it involves > building PyQt5 and bundling it with the application. This. I have got three applications using PyQt5, either directly or via a shim module like QtPy, and a KDE runtime with PyQy5 already included would definitely help.
I was wondering the same. Also reassigned “Qt/KDE Flatpak Runtime” as that is were https://invent.kde.org/packaging/flatpak-kde-runtime/ points to.
I've thought about doing something about it but I don't think it's worth the effort at this point, especially considering how there's both PySide (Qt for Python now) and PyQt5. It would surely be possible to have an extra org.kde.python.Platform kind of thing. Or an extension should be possible as well, haven't explored this approach, it would be welcome if someone did. The biggest problem with basing the platform is that we'd have to choose against Qt WebKit and Qt WebEngine, which is another crazy place that adds complexity. It would also be possible to include a PyQt and QtForPython module in https://github.com/flathub/shared-modules. Maybe it's something worth considering. If you're working on it now, you can copy the packaging I already did for QGIS: https://github.com/flathub/org.qgis.qgis/blob/master/org.qgis.qgis.json
> I've thought about doing something about it but I don't think it's worth the effort at this point, especially considering how there's both PySide (Qt for Python now) and PyQt5. Could you explain the difference between PySide and PyQt5 and why I've never seen a Python Qt application using the former (although it supposedly is the “official” binding)? > It would surely be possible to have an extra org.kde.python.Platform kind of thing. Or an extension should be possible as well, haven't explored this approach, it would be welcome if someone did. A separate platform would be overkill, but a runtime extension could be decent compromise there. Although I was secretly hoping to have it in the main platform image, as Python support in FDO/GNOME runtimes is available OOTB and as a Python programmer I of course love that. :-P > The biggest problem with basing the platform is that we'd have to choose against Qt WebKit and Qt WebEngine, which is another crazy place that adds complexity. I'm sorry, I don't understand what you mean with “basing” here? QtWebEngine/QtWebKit are not part of this and at least PyQt5 allows building the Python binding for QtWebEngine separately. (OT: Regarding that, I had been privately wondering if wouldn't make sense to have these as runtime extensions [with their respective Python bindings].)