The PyQt6 dependency about mne-python

[cbrnr]

I know, this is really frustrating. I would try to go for PySide for two reasons: (1) it's the officialy Qt bindings for Python, and (2) they have a better license (LGPL vs. PyQt's GPL) which might be "more compatible" with BSD/MIT licenses.

[mscheltienne]

I actually use plt.ion() in non jupyter/IPython kernel, for instance to display topographic map which updates based on events. What is the issue with using qtpy and not providing any Qt binding in our installation, relying entirely on the user to install one?

[mscheltienne]

For sure, I would not provide PySide2 or PySide6 by default if it yields broken interactive plots. As for adding a mne[full-no-qt] option, sure, why not.

[cbrnr]

Yes, only PySide has aarch64 wheels. Plus it is always more up to date, currently it's at 6.7.1, which fixes segfaults on macOS that occur with 6.7.0. PyQt is still at 6.7.0.

[hoechenberger]

How "important" is the interactive plotting problem really, anyway? I never encounter it because a) I never use plot.ion(); b) during interactive use, I run my stuff in Jupyter / IPython anyway, where the issue does not occur. But I'm not sure how others do it.

It seems the only place we even mention plt.ion() in the MNE docs is in the UI Events tutorial.

[hoechenberger]

What is the issue with using qtpy and not providing any Qt binding in our installation, relying entirely on the user to install one?

Well exactly that: it would require users to install something additional that is in fact a hard dependency and should, therefore, be installed automatically for them. It's both inconvenient and a packaging bug, as a package manager wouldn't be able to determine that MNE actually depends on that particular Qt binding.

[hoechenberger]

I actually use plt.ion() in non jupyter/IPython kernel, for instance to display topographic map which updates based on events.

Interesting, what does that look like? Do you have a minimal script you could share? (out of general interest!)

Would there be any chance you could run the same script in IPython?

[mscheltienne]

Interesting, what does that look like? Do you have a minimal script you could share? (out of general interest!)

It's a small demo we use on our site with dry-electrode EEG systems. I have to fire it up tomorrow, I'll record it and share the associated script.

Would there be any chance you could run the same script in IPython?

Sure it would, but I prefer to start it through an terminal entry-point from the package. In my case however, it's a non blocking issue as I use pip to install everything.

---

Now back to the subject:

Well exactly that: it would require users to install something additional that is in fact a hard dependency and should, therefore, be installed automatically for them.

I agree, but Qt is a bit special within our dependencies exactly because it has 4 different bindings which offers similar functionalities and that in advance/expert scenarios you might want to install one binding instead of another one. IMO, we should differentiate 2 user populations:

• python beginners, who will use the MNE installers -> includes a python binding and they don't even know about what's actually installed, where, and so on.
• intermediate and advance python users, who do not use the MNE installers -> in this case, I consider that they can read the error message yielded by qtpy and figure out that they have to install one of the 4 bindings.

This can be further backed with documentation in the install section of our website, which already separates those 2 populations.

[hoechenberger]

It's a small demo we use on our site with dry-electrode EEG systems. I have to fire it up tomorrow, I'll record it and share the associated script.

That would be awesome, thanks! :)

I agree, but Qt is a bit special within our dependencies exactly because it has 4 different bindings which offers similar functionalities and that in advance/expert scenarios you might want to install one binding instead of another one.

Yeah but why not provide something that works out-of-the-box (as we do now) for most users, and add in an additional variant (e.g., mne[full-no-qt] or something) for those who need to pick a different binding?

We currently do make the choice already, as we depend on PyQt6. So this is what everyone gets when installing mne[full]. I need an additional way to special-case my scenario. Unless we switch the dependency to PySide6 altogether.

[hoechenberger]

Another argument against PyQt6 (and in favor of PySide6): there's no PyQt6 wheels for aarch64 on PyPI. I contacted the developers about if and when this might happen, and the response was something like, "maybe someday" (I cannot find the original posting anymore)

[hoechenberger]

I've opened #12628

Any feedback appreciated

[hoechenberger]

Another argument against PyQt6 (and in favor of PySide6): there's no PyQt6 wheels for aarch64 on PyPI. I contacted the developers about if and when this might happen, and the response was something like, "maybe someday" (I cannot find the original posting anymore)

I found it again:

https://gitlab.kitware.com/vtk/vtk/-/issues/18648#note_1526361

[cbrnr]

But this is about VTK and not PyQt/PySide?

[hoechenberger]

Oh. Right. I'm getting all confused here… sorry.
But I believe for PyQt6, there weren't any aarch64 wheels either.