Make full installation depend on PySide6 by default

[hoechenberger]

Since the bug with interactive plotting when using PySidd6 has now been fixed, we should be able to replace the PyQt6 dependency in mne[full] with PySide6.

• PySide6 is the official Qt for Python binding.
• Binary wheels of PySide6 are available for more platforms, including aarch64.
• The conda-based installation – which is what we recommend in our docs – and our installers will use PySide6 starting with the next MNE-Python release.
• PySide6 is available from conda-forge, while PyQt6 is not (yet). Switching the dependency to PySide6 will make for a cleaner and smoother experience in situations where a conda-forge and PyPI-based installation of MNE-Python are mixed.

The abovementioned bug fix should be included in the upcoming release 6.7.3.

Lastly, probably more controversial, but: my opinion is that once we've made the switch, we can (should) drop support for PyQt and get rid of qtpy, which just adds another layer of complexity that
won't be needed anymore: PySide is the official binding, has a more permissive license, and is more actively developed.

[cbrnr]

I agree 💯%! Once PySide6 is available and works, qtpy is obsolete because there is no need to support another Qt binding such as PyQt.

There are two points in favor of PySide6 that I'd like to highlight more explicity:

• PySide6 is licensed under the LGPL, whereas PyQt6 uses the GPL. It's not entirely safe to use GPL-licensed code in a BSD- or MIT-licensed project.
• PySide6 is being updated to the latest Qt versions much more rapidly and frequently (probably because it is the official binding). For example, PyQt6 has been stuck at 6.7.0 for months now, whereas PySide6 closely follows the Qt release cycle.

[larsoner]

Okay with switching to a PySide6>=6.7.3 pin once it actually lands.

I'd rather not get rid of qtpy -- it has very little maintenance overhead / burden for us and makes our library compatible with more Qt bindings, including PyQt5 which is still widely used on conda-forge. Maybe in a year or two once things settle it could make sense to switch to PySide6, but I don't think we should move fast on this.

[cbrnr]

I think people should not be using an old Qt binding, and dropping qtpy would ensure that. I understand if you don't want to do it right now, but we should eventually get rid of it (a year or two seems too long, let's maybe reconsider in half a year or so).

[hoechenberger]

(on a somewhat related side node I always found it extremely funny that it's the Spyder devs who came up with qtpy, yet not only does Spyder explicitly depend on PyQt5, but even on a very specific version of it -- in addition to qtpy. I find this ironic and it kind of impairs my trust in the approach qtpy has taken -- it seems not even its own devs trust it enough to do the job full and well.)

[wmvanvliet]

-1 from me on dropping qtpy because I would like Qt5 support a bit longer. On our workstations in our department, we don't update our entire anaconda environment that fast and the machines used by our researcher to get their daily work done are still on Qt5 (because Qt6 is not available yet through conda-forge).

[cbrnr]

Qt6 is available through conda-forge via PySide6.

[hoechenberger]

Yes Qt6 has been available on conda-forge for almost 2 years now. Qt6 is more than 3.5 years old.

Honest question, if the workstations don't get updated anyway – can you not just stick with an older MNE-Python, then?

[hoechenberger]

That said I don't feel strongly about qtpy, so for now i'm rather neutral on this one. I just think it's one bit we should definitely consider getting rid of whenever we believe it's convenient!

[wmvanvliet]

Yes Qt6 has been available on conda-forge for almost 2 years now. Qt6 is more than 3.5 years old.

Honest question, if the workstations don't get updated anyway – can you not just stick with an older MNE-Python, then?

wow I feel silly. I always thought pyqt6 would be the official package, but it is pyside6 and that has been available for a long time. I never knew. The solver always refused to install pyside6 because we are also users of Spyder, which depends on pyqt5... This is an informative thread for me.

[hoechenberger]

Yes Spyder is super odd, they do use qtpy but depend on PyQt5 😵‍💫
And I don't think you're the first one who believes PyQt6 is the official binding. In fact I would bet the majority of Python users would answer this question incorrectly. It's such a mess on many levels. PyQt6 simply has the much better name.

[larsoner]

FYI I just tried to use PyQt6 and then PySide6 with vscode's Python debugger and ran into microsoft/debugpy#1488 and microsoft/debugpy#1569. So Qt6 support is still in the works / incomplete in VSCode in addition to conda and Spyder apparently!

[larsoner]

Looks like @wmvanvliet has been busy trying to make things better there at least :)

microsoft/debugpy@0035e83