Closed larsoner closed 4 months ago
@larsoner The problem here seems to be that graphviz
pins to libexpat >=2.6.2
, but vtk-base
needs an older version (<2.6
)
Actually … no, disregard my previous comment, this doesn't check out, at least on my Apple Silicon Mac:
❯ conda search vtk-base==9.3.0 --info |grep libexpat
- libexpat >=2.6.2,<3.0a0
- libexpat >=2.6.2,<3.0a0
- libexpat >=2.6.2,<3.0a0
- libexpat >=2.6.2,<3.0a0
- libexpat >=2.6.2,<3.0a0
❯ conda search graphviz==11.0.0 --info |grep libexpat
- libexpat >=2.6.2,<3.0a0
Some new Mayavi builds have been published less than an hour ago, maybe they'll fix the issue? :D
Edit: just now realizing it what you who did that! As usually, you seem to have everything under control 😄
Now it looks like at least https://github.com/conda-forge/liblsl-feedstock/pull/11 is in the way
Now held up by
macos-11 is no longer available, I'll tweak then we should be good @hoechenberger , feel free to mark for merge-when-green if you're happy!
I dropped yasa because it's blocking a SciPy upgrade and they haven't merged my PR to fix things (and then cut a release), hope that's okay
Ooof looks like there is a problem with vtk 9.3.0 (and upward) -- it's built against qt6-main
. One way forward would be to follow https://github.com/conda/constructor/issues/515 and package our own PyQt6. WDYT @hoechenberger ?
... or just hope people don't use plain Python + interactive mode + plotting and stick with PySide6 :(
@larsoner More and more conda-forge packages are migrating to qt6 (and hence pyside6). So this is something we'll have to deal with anyway. An alternative would be to switch our installers away from conda and install everything from PyPI. This should work for all platforms except for aarch64. It's what I do in my dev container PR except for vtk and a few other packages (since they're missing for aarch64 on PyPI). But we currently don't provide installers for aarch64 anyway so...
And yes we wouldn't be able to bundle as many tools as we're doing now, this is clear
Or maybe someday https://github.com/conda-forge/pyqt-feedstock/pull/136 will land :crossed_fingers:
I find this an extremely annoying situation esp since PySide6 is the official Qt binding. Why isn't plotting working properly with it???!
cc @cbrnr
Same as before, https://bugreports.qt.io/browse/PYSIDE-2192
yep...
@cbrnr Have you had any chance to test whether it's working on Py3.13?
Not yet, but I will try!
Unfortunately, PySide6 does not support 3.13 yet.
This is close. One blocker is actually Spyder because it explicitly depends on pyqt
.
But why is pyqt problematic?
Because there are only PyQt5 builds (no PyQt6) which means it pulls in qt-main in addition to qt6-main and this causes problems
Ah, I misread that as qtpy. Too many qt py side 5 6 I guess 😄. It's weird that Spyder does not only depend on qtpy though, since I thought they develop and maintain qtpy as an integral part of Spyder...
@cbrnr afaik their resources are super limited and they didn't have the time to test with qt6 yet
@larsoner We could consider dropping Spyder and guiding users to the Spyder standalone installers. We'd need to provide some setup script to deploy a proper configuration to make it easy to use MNE (installed via the MNE installers) though ...
Hah, apparently we left automerge enabled! But that's okay -- I think for 1.8 we probably should drop Spyder from our installers and point people toward their standalone installers. I don't think it'll be too bad to configure it to use our Python distribution/kernel because we install spyder-kernels
here. But it's something we should do for 1.8 docs. I'll open an issue in MNE-Python and tag for 1.8 so we don't forget.
thanks Eric! the inclusion of MNELAB is worth it!
speaking of which, we should probably add it to the installer menu
it's something we need to take care of in the mne-feedstock repo
Somewhere we have a note about moving the installer menu stuff to this repo, is that still possible? If feel free to give it a shot, or if you know if another project that does it in the constructor I can look at their code and adapt.
I'll look at Spyder and Napari at least to see if they have something to work from
Closes #82 Closes #250