Make full installation depend on PySide6 by default

mne-tools / mne-python

MNE: Magnetoencephalography (MEG) and Electroencephalography (EEG) in Python

https://mne.tools

BSD 3-Clause "New" or "Revised" License

2.7k stars 1.31k forks source link

Make full installation depend on PySide6 by default #12709

Open hoechenberger opened 3 months ago

hoechenberger commented 3 months ago

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 commented 3 months ago

I agree :100:%! 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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

(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 commented 3 months ago

-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 commented 3 months ago

Qt6 is available through conda-forge via PySide6.

hoechenberger commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 2 months ago

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

larsoner commented 2 months ago

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

https://github.com/microsoft/debugpy/commit/0035e83a40ba77080f9ae8b829835b2a0c4834f6