volpy gui doesn't work with Qt6 (or Qt5, except on some platforms)

[pgunn]

The volpy gui doesn't seem to work with qt6, which is delivered by default with most environment solves; it has a dependency on PyQt5.

It's unclear how hard it would be to update caiman/source_extraction/volpy/volpy_gui.py to accept qt6.

@caichangjia giving you a heads-up on this; I'll look into it too but you're much more familiar with that code.

[pgunn]

Hm. Merely installing pyqt into the environment also doesn't seem to produce a working app.

scclin022:~/caiman_data$ python /mnt/home/pgunn/src/caiman_dev/caiman/source_extraction/volpy/volpy_gui.py
2025-01-21 14:13:25.410789: I tensorflow/core/util/port.cc:113] oneDNN custom operations are on. You may see slightly different numerical results due to floating-point round-off errors from different computation orders. To turn them off, set the environment variable `TF_ENABLE_ONEDNN_OPTS=0`.
2025-01-21 14:13:25.447661: E external/local_xla/xla/stream_executor/cuda/cuda_dnn.cc:9261] Unable to register cuDNN factory: Attempting to register factory for plugin cuDNN when one has already been registered
2025-01-21 14:13:25.447697: E external/local_xla/xla/stream_executor/cuda/cuda_fft.cc:607] Unable to register cuFFT factory: Attempting to register factory for plugin cuFFT when one has already been registered
2025-01-21 14:13:25.448693: E external/local_xla/xla/stream_executor/cuda/cuda_blas.cc:1515] Unable to register cuBLAS factory: Attempting to register factory for plugin cuBLAS when one has already been registered
2025-01-21 14:13:25.454339: I tensorflow/core/platform/cpu_feature_guard.cc:182] This TensorFlow binary is optimized to use available CPU instructions in performance-critical operations.
To enable the following instructions: SSE4.1 SSE4.2 AVX AVX2 AVX512F AVX512_VNNI FMA, in other operations, rebuild TensorFlow with the appropriate compiler flags.
Qt: Session management error: None of the authentication protocols specified are supported
QWidget: Must construct a QApplication before a QWidget
Aborted (core dumped)

[pgunn]

Ah, that warning or error can be solved by unsetting the SESSION_MANAGER env var. Still core dumping on me; unclear why.

[pgunn]

So unsetting SESSION_MANAGER solves the session management error, but the QWidget error that causes the core dump comes from the first call to pyqtgraph; this may be caused by both qt5 and qt6 installed in my current test environment. Looking into whether a pure qt5 environment crashes.

[pgunn]

Apparently only the pyqt5 bindings are installed, so it's not that; it's something else.

We also can't port this until there's good packaging for pyqt6 in conda-forge. So we have to put this issue on hold.

[pgunn]

I just spent a fair bit more time looking into why our app now crashes on startup (even though we're not trying to use Qt6), and I have an answer I'm reasonably sure of.

On conda-forge, the pyqt package is stuck on PyQt5. It's unclear why this is the case, but people have made workarounds for this and related PyQt versioning issues using a package called PySide6. PySide6 seems to be a different implementation of PyQt6 (or perhaps a generic PyQt-any-version binding?).

matplotlib, which we import, switched to using PySide6 late last year: conda-forge/matplotlib-feedstock#393
pyqtgraph also pulls in pyside6, in a bunch of dizzying conditional imports:

​​from PySide2.QtWidgets import *
​​from PyQt5.QtWidgets import *
​​from PySide6.QtWidgets import *
​​from PyQt6.QtWidgets import *

What this means though is that any application that uses pyqt (aka PyQt5) and pyqtgraph in an environment where matplotlib is present is going to be broken, because if the application creates a QApplication with PyQt5, pyqtgraph will not be able to recognise it because it's not a Qt6 version of QApplication, so it will throw up its hands and crash (probably better than continuing on and crashing in a more subtle way; there's already no way to win at that point).

import pyqtgraph
import PyQt5
import sys
import PyQt5.QtWidgets
app = PyQt5.QtWidgets.QApplication(sys.argv)
w = PyQt5.QtWidgets.QWidget()
​​>>> PyQt5.QtWidgets.QMenu()
​​<PyQt5.QtWidgets.QMenu object at 0x7fb7147af1c0>
​​>>> pyqtgraph.QtWidgets.QMenu()
​​QWidget: Must construct a QApplication before a QWidget
​​Aborted (core dumped)

If there's a good way to solve this, I don't know what it is; in theory pyqtgraph could be more careful with that set of imports to try to figure out if the app has already committed to Qt5 or Qt6, but that may be fragile.

[pgunn]

For now, I think I see a few routes forward:
A) We pin an older version of matplotlib that doesn't bring in pyside6
B) We look for some syntax in our environment.yaml to ban installation of pyside6
C) We commit to pyside6 and PyQt6 and port all our code to it

C feels the most future-friendly, but I'm not sure if there will be any hiccups from that.

[pgunn]

It turns out that porting the volpy gui to use pyside6 is trivial; took me less than 5 minutes.

[pgunn]

Apparently has issues on OSX; see #1451. Hopefully will not take too much work to resolve.

[caichangjia]

thank you~ @pgunn