[baradejoo]

Summary

• patch/ros-lyrical-python-qt-binding.patch: python_qt_binding 2.5.5 (lyrical) hardcodes DEFAULT_BINDING_ORDER = ['pyside'] on macOS, but RoboStack ships PyQt6 and not PySide6, so every Python-based rqt tool fails to start on macOS:

ImportError: Could not find Qt binding (looked for: 'pyside'):
  ImportError for 'pyside': No module named 'PySide6'

The patch is a backport of upstream ros-visualization/python_qt_binding#156 (merged into rolling, not released for lyrical yet), which uses ['pyqt', 'pyside'] on all platforms. ros-jazzy and ros-kilted already carry the same patch (patch/ros-jazzy-python-qt-binding.patch, patch/ros-kilted-python-qt-binding.patch).

• Bump python_qt_binding build number to 28 so it gets rebuilt.

Remaining runtime issue

With this patch rqt gets past the binding selection, but on osx-arm64 it still crashes at startup during plugin discovery:

$ pixi run rqt
QMetaMethod::invokeMethod: return type mismatch for method Settings::contains(QString): cannot convert from void to bool during invocation
libc++abi: terminating due to uncaught exception of type std::runtime_error: Settings::contains() invoke method failed

The call comes from qt_gui_cpp::RosPluginlibPluginProvider::discover_descriptors() → qt_gui_cpp::Settings::contains(), invoking the Python slot qt_gui.settings.Settings.contains (declared as @Slot(str, result=bool)). Inspecting the metaobject of that instance shows that all its slots are registered with return type void, so the result= of pyqtSlot is lost.

I could reproduce this with plain PyQt6 (conda-forge pyqt6 6.11.0, qt6-main 6.11.2, Python 3.14), without any ROS code, and the result is not deterministic (the same script sometimes reports bool, sometimes void, depending on which objects were created before):

from PyQt6.QtCore import QObject, pyqtSlot, QMutex

class P(QObject):
    def __init__(self):
        super().__init__(); self.setObjectName('SettingsProxy'); self._m = QMutex()
    def contains(self, g, k): return True

class S(QObject):
    def __init__(self):
        super().__init__(); self.setObjectName('Settings')
    @pyqtSlot(str, result=bool)
    def contains(self, key): return True

p = P(); s = S(); mo = s.metaObject()
print(mo.method(mo.indexOfMethod(b'contains(QString)')).typeName())  # 'bool' or 'void'

So it looks like a PyQt6/sip issue rather than something in qt_gui_core. I only tested on osx-arm64, so I don't know whether linux is affected as well.

@traversaro @Tobias-Fischer how would you like to handle this? Should I report it to conda-forge/pyqt-feedstock (or upstream PyQt), or is there a known workaround/pin you'd prefer? This PR only fixes the binding selection, I'm happy to follow up separately.

Notes

Tested locally on osx-arm64: python_qt_binding builds with the patch and rqt now loads PyQt6 instead of failing on the missing PySide6.

[traversaro]

@traversaro @Tobias-Fischer how would you like to handle this? Should I report it to conda-forge/pyqt-feedstock (or upstream PyQt), or is there a known workaround/pin you'd prefer?

Let's do both. If the issue is not reported upstream, please report it, and then if you add a local workaround here, use the issue as a reference in the the workaround you implemented.

[baradejoo]

I reported it upstream in conda-forge/pyqt-feedstock#201.

It looks specific to the conda-forge builds rather than a Qt or PyQt issue: with pyqt6 6.11.0 _4 + qt6-main 6.11.2 from conda-forge, pyqtSlot(result=...) return types end up registered as void in the meta-object, while the same script works with qt6-main 6.11.1 from conda-forge and with the official PyPI wheels (PyQt6 6.11.0 + PyQt6-Qt6 6.11.2). The issue has a minimal reproducer without ROS.

A local workaround here is possible, but both options I found are not great:

• Pin qt6_main to 6.11.1 and rebuild the 25 packages that were built against 6.11.2 (similar to Pin qt6-main and pyqt6 to 6.11; rebuild packages built against qt6-main 6.12 #65).
• Patch qt_gui_cpp::Settings to call the Python slots through QMetaObject::metacall instead of QMetaObject::invokeMethod, which skips the return type check against the broken meta-object. I have a prototype that gets rqt past startup on osx-arm64, but it only fixes this call site, so other places that invoke Python slots with a return value from C++ would still be affected.

So I'd suggest waiting for a fix on the conda-forge side (e.g. a pyqt6 build compatible with qt6-main 6.11.2) and keeping this PR limited to the python_qt_binding fix. If you'd prefer to have a workaround in the meantime, let me know which option you'd like and I'll add it with a reference to the issue.

[baradejoo]

The PyQt issue is fixed upstream now, so no local workaround is needed here:

The already published lyrical packages don't need a rebuild, they allow pyqt6 >=6.11.0,<6.12.0a0, so a fresh environment picks up _6. This PR only carries the python_qt_binding#156 backport, which is still needed on macOS.

Tested on osx-arm64 in a fresh environment with the published qt_gui_cpp and python_qt_binding from this PR:

$ pixi list | grep -E 'pyqt6|qt6-main|qt-gui-cpp|python-qt-binding'
pyqt6                    6.11.0   py314ha630e2e_6        https://prefix.dev/conda-forge
pyqt6-sip                13.13.0  py314ha630e2e_6        https://prefix.dev/conda-forge
qt6-main                 6.11.2   pl5321hf0f7225_0       https://prefix.dev/conda-forge
ros2-python-qt-binding   2.5.5    np2py314hdc941bd_28    file:///.../ros-lyrical/output
ros2-qt-gui-cpp          2.11.1   np2py314h289bcd9_27    https://prefix.dev/robostack-lyrical
ros2-rqt-gui-cpp         1.10.6   np2py314hda44873_27    https://prefix.dev/robostack-lyrical
$ pixi run rqt

rqt starts and the plugins load. On exit it still aborts with mutex lock failed: Invalid argument (from class_loader::ClassLoader::~ClassLoader() during static destruction). That's a separate macOS issue in class_loader / console_bridge, not related to this PR.

[Tobias-Fischer]

See RoboStack/robostack#60