API: Deprecate mayavi

[larsoner]

• Copy-paste-adapt-CI code to https://github.com/mne-tools/mne-kit-gui
• Merge ENH: Coreg GUI #9689
• Do PyPi release of mne-kit-gui
• Make mne-kit-gui conda-forge package (Adding mne-kit-gui conda-forge/staged-recipes#16660)

Closes #9753

[larsoner]

Seems to be working:

$ mne kit2fiff
<decorator-gen-565>:4: DeprecationWarning: Function kit2fiff is deprecated; The `mne kit2fiff` command will require the mne-kit-gui module after 0.24, install it using conda-forge or pip to continue using this utility.
$ pip install mne-kit-gui
Defaulting to user installation because normal site-packages is not writeable
Collecting mne-kit-gui
  Downloading mne_kit_gui-1.0.1-py3-none-any.whl (42 kB)
     |████████████████████████████████| 42 kB 473 kB/s 
...
$ mne kit2fiff

@christianbrodbeck can you see if you're happy with the instructions and such? I think the last step is to get conda-forge/staged-recipes#16660 merged and double check that the conda-forge package is actually there.

[agramfort]

Amazing !!!

[christianbrodbeck]

There still seem to be a number of imports of private functions from mne, would it make sense to just make those functions public in mne to make the authors of future changes aware that these should be stable API?

[larsoner]

just make those functions public in mne to make the authors of future changes aware that these should be stable API?

I'd rather follow up any private changes in MNE with changes in this repo when necessary. I think it will require less work than adding more stuff to the MNE public API (which already probably has too much public stuff). MNE-Realtime, MNE-Connectivity, and (much longer duration) autoreject use private functions from MNE and it hasn't required too many changes over the years.

[christianbrodbeck]

Does it make a difference that I rarely work with KIT data anymore? Anything that breaks will very likely be noticed by end users rather than developers...

[agramfort]

Does it make a difference that I rarely work with KIT data anymore? Anything that breaks will very likely be noticed by end users rather than developers...

none of the mne devs are KIT users. So you are still the best person for this :)

[christianbrodbeck]

none of the mne devs are KIT users. So you are still the best person for this :)

I did not mean to pull out of this :) but I meant that in the case that private mne API changes were to break the GUI I would be unlikely to notice before the release, and instead end users would run into cryptic error messages...

[agramfort]

we could have the CI run weekly on the mne_kit_gui repo to detect issues early?

…

[christianbrodbeck]

Ok, yes, that should catch most of it.

[larsoner]

@christianbrodbeck last night I got an email from Azure about mne-kit-gui, hopefully got one, too. That means emails work. It said that the build passed, which just pointed out that I forgot to add the additional conditional to only email when the status is failed. I've done that so I think it will do that now! I set it to run daily rather than weekly since it's quick enough.

I've also checked and now the usage instructions in the readme work for me. Feel free to try @christianbrodbeck ! In the meantime @agramfort feel free to merge this

[larsoner]

Just saw you approved so I'll go ahead and do it!