Mne-python: Following the installation instructions for macOS yields an error message

[hoechenberger]

Describe the bug

Following the installation instructions for macOS in the development version of the docs produces an error message, not a working MNE-Python installation

Steps to reproduce

Download the conda environment file from https://raw.githubusercontent.com/mne-tools/mne-python/master/environment.yml

Run

conda env create -f environment.yml -n mne-test

Expected results

A working environment should be created.

Actual results

Installation fails due to an unsatisfiable dependency:

Pip subprocess error:
ERROR: Could not find a version that satisfies the requirement vtk<8.2 (from -r /private/tmp/condaenv.fkd0fvyw.requirements.txt (line 4)) (from versions: 9.0.0, 9.0.1)
ERROR: No matching distribution found for vtk<8.2 (from -r /private/tmp/condaenv.fkd0fvyw.requirements.txt (line 4))


CondaEnvException: Pip failed

Additional information

This is due to the fact that python is pinned to >= 3.5 and vtk is pinned to < 8.2 on macOS. This will first install Python 3.8 (via conda) and bomb during pip install of vtk, because the only wheels available for Python 3.8 are for VTK 9.

VTK was pinned to version 8 on macOS because of some issues with version 9.

Since conda environment files do not support selectors, there are currently only 3 solutions to this problem:

• fix the bugs that keep us from using VTK 9 on macOS
• provide a separate environment file for macOS, which pins Python to < 3.8
• suggest that users install the conda-forge package of MNE-Python, as the "clean" way to declare system-dependent requirements in conda land is by producing separate packages

cc @GuillaumeFavelier

[GuillaumeFavelier]

Thanks for opening this @hoechenberger !

I have no ETA for 1) and I'm unable to debug on MacOS, maybe we could work on it together offline?

Meanwhile, between 2) and 3) I don't know what's the best. Any idea @larsoner , @agramfort ?

[agramfort]

how come this is working on CIs? can we modify the env such that it's using
python 3.7 if mac os? without creating a new environment file.

>

[GuillaumeFavelier]

how come this is working on CIs?

The default on the CIs is python 3.7:

https://github.com/mne-tools/mne-python/blob/master/.travis.yml#L19

And the python 3.8 job on Travis uses Linux:

https://github.com/mne-tools/mne-python/blob/master/.travis.yml#L33-L37

[GuillaumeFavelier]

We do something like this for vtk:

  - vtk<8.2; platform_system == "Darwin"
  - vtk; platform_system != "Darwin"

It does not work for python in your environment file @hoechenberger ?

[hoechenberger]

We do something like this for vtk:

  - vtk<8.2; platform_system == "Darwin"

  - vtk; platform_system != "Darwin"

It does not work for python in your environment file @hoechenberger ?

That is what we currently do. But this doesn’t respect that there is no VTK that would satisfy this requirement for Python 3.8. And you cannot use selectors in the environment file to pin Python to a specific version for a specific platform. That it works for pip packages is only a lucky coincidence:)

[hoechenberger]

Reading your question again I now see I slightly misunderstood it. The answer is: no, it wouldn’t work.

[agramfort]

but if you set a global like PYTHON_VERSION=3.7 you can fix the issue?

[larsoner]

but if you set a global like PYTHON_VERSION=3.7 you can fix the issue?

I think that is ci-helpers specific, but I'm not sure.

Two options:

1. Just use vtk from conda
2. Set python<3.8 in environment.yml

(2) has the disadvantage of making all platforms use < 3.8 when only OSX needs it. (1) should work at least until conda provides VTK 9 for macOS, but maybe if it's pointed out that it doesn't work they won't bother (?). Originally I was optimistic that using VTK9 would fix a lot of bugs like depth buffer issues seen on 8.1.2 and 8.2.0, but it doesn't seem to have done that, so I think I prefer (1).

[GuillaumeFavelier]

I'll try 1)

[larsoner]

Already on it, about to make a CI PR

[cbrnr]

In the long run it would be great if everything worked with VTK 9 though...

[larsoner]

Indeed, but VTK9 rendering on macOS seems to be pretty broken and I think the VTK folks need to fix it

[cbrnr]

I'll see if 9.0.1 changed anything for the better though.

[GuillaumeFavelier]

Thanks for letting us know, that would mean that we don't need to pin vtk anymore for MacOS

[cbrnr]

Yeah, I still get the black figure with 9.0.1 unfortunately.

[GuillaumeFavelier]

can you try a very simple pyvista script @cbrnr ? The issue could totally be in the mne implementation.

import pyvista as pv
from pyvistaqt import BackgroundPlotter

p = BackgroundPlotter()
p.add_mesh(pv.Cone())

Expected result:

[cbrnr]

Yes, I actually think it's the implementation, because you do draw a black image to reduce/eliminate flickering. It's probably drawn in the wrong order or something. This simple example works fine (although it uses pyvistaqt in contrast to what I tried in the notebook, but I guess this doesn't make a difference).

[GuillaumeFavelier]

If it works with this simple example, there is a way to make it work on mne, I'll open a issue/PR about that but I need help to try it out on MacOS.

Can I assume that it still does not work for you with the notebook 3d backend with vtk 9.0.1 @cbrnr ? Let's come back to this one after we solve this.

[larsoner]

The simple example works for me, I'll see if I can figure out how to make stc.plot work

[cbrnr]

@GuillaumeFavelier I can help with macOS testing of course! Right, the notebook example still shows a black image with VTK 9.0.1.

[hoechenberger]

I can test on macOS too, but I didn't experience the issue @cbrnr had, so not sure if I can be of much help?

[cbrnr]

cf https://github.com/pyvista/pyvistaqt/issues/15 for details on the example script