Trouble installing Spyder into MNE conda environment

[hoechenberger]

@SophieHerbst reported trouble getting Spyder to work in the MNE conda environment which she created by following the official installation instructions on macOS.

I could reproduce the issue, which is essentially caused by the fact that our environment file creates a horrible mess by first installing PyQt via conda (implicitly, as a dependency of other packages) and then again (explicitly) via pip; this is expected to break.

A quick and super ugly workaround seems to be the following, which creates a working Spyder installation for me:

conda create -c defaults -n mne-spyder-test python=3.7 spyder
conda activate mne-spyder-test
curl --remote-name https://raw.githubusercontent.com/mne-tools/mne-python/master/environment.yml
conda env update -n mne-spyder-test -f environment.yml
conda remove --force pyqt
pip install -U "pyqt5>=5.10,<5.13"
pip install -U "pyqtwebengine>=5.10,<5.13"

The reason we're installing PyQt5 (and packages that depend on it) via pip seems to be that the latest version on the defaults conda channel is 5.9; yet we need at least version 5.10. I therefore propose we move away from the defaults channel and switch to conda-forge, from where we could get up-to-date releases of almost all of our dependencies. This would have avoided the recent VTK mess, too.

(Simply retrieving pyqt from conda-forge and installing the rest from defaults is bound to produce problems; it's discouraged to mix defaults and conda-forge packages in the same environment)

WDYT?

[cbrnr]

:+1: for switching to conda-forge. The defaults channel often lags behind several versions for a very long time.

[drammock]

It has always bothered me that an IDE would be installed into an environment and share dependencies with other packages one needs for one's work. I really wish they would provide installable binaries for all platforms. /end_rant

For cases of dependency conflict, Spyder's docs now recommend installing it into its own environment and setting its executable to the one in the mne environment. Perhaps we should provide a clear walk through of how to do this in our docs (since many of our users seem to like Spyder)?

[hoechenberger]

It has always bothered me that an IDE would be installed into an environment and share dependencies with other packages one needs for one's work. I really wish they would provide installable binaries for all platforms. /end_rant

Yes it's super bad, and I really mean super bad, but the devs still didn't get around fixing this, unfortunately. It's on their todo list (virtual env switcher), but as far as I know doesn't have an ETA.

For cases of dependency conflict, Spyder's docs now recommend installing it into its own environment and setting its executable to the one in the mne environment. Perhaps we should provide a clear walk through of how to do this in our docs (since many of our users seem to like Spyder)?

Personally I'm against making the installation process even more complicated than it already is. It's already difficult enough for new users to get started; if anything, we should provide them with something that works out of the box – and realizing Spyder is so popular, maybe we should go back to bundling it with the environment targeted towards end users, as we used to.

I'm also considering creating an installer, which is easy to do with conda packages. Maybe I should just bite the bullet and move ahead with this next weekend or so…

[hoechenberger]

@drammock In any case, switching to conda-forge-based dependencies (#7946) would make things a lot smoother already; we could even create our own deployment based on Miniforge. That would be neat…

[hoechenberger]

FWIW, I recommended PyCharm to @dnacombo; however, the free Community Edition has pretty limited functionality compared to the Professional version, which is unfortunate. And it's at least a year or two too early to suggest users pick VS Code, IMHO… So. This only leaves Spyder, I'm afraid.

[drammock]

Personally I'm against making the installation process even more complicated than it already is.

Agreed, though since spyder is installed into base environment by default as part of the standard anaconda distribution, this is what it would look like:

# create new environment "mne"
curl --remote-name https://raw.githubusercontent.com/mne-tools/mne-python/master/environment.yml
conda env update -n mne --file environment.yml  # after editing env file to include spyder-kernels
# get the path to its executable
conda activate mne
python -c "import sys; print(sys.executable)"
# switch back to base and launch spyder
conda activate base
spyder
# now, set the python interpreter in the Spyder menus (Tools > Preferences > Python interpreter)  as described here https://github.com/spyder-ide/spyder/wiki/Working-with-packages-and-environments-in-Spyder#working-with-other-environments-and-python-installations

After that it should always be "launch spyder and do your work".

[hoechenberger]

@drammock I was told that the reasoning behind the switch from "create a dedicated MNE environment" to the current "just dump everything in base, f*ck it!" in the installation instructions was that many (Python) newcomers already have so much new to learn, and virtual environments just added to this complexity and made the onboarding procedure much harder.

I do not like the current approach; yet I do see the point.

I would suggest we really sit down and start brainstorming how to make it easier to get started with MNE, i.e., how to get it installed more easily. Python and MNE are difficult enough on their own… and now there's yet another difficulty: picking and setting up an IDE. I claim this is simply off-putting to new users, unless they're very tech-savvy.

What do you think about the idea of creating a standalone "MNE" installer, which creates a conda installation that's independent of other Python installs on the system, and ships with a ready-to-use Spyder?

[drammock]

many (Python) newcomers already have so much new to learn, and virtual environments just added to this complexity and made the onboarding procedure much harder.

Yes. What I'm suggesting above only requires dealing with environments once, during installation. After that, any time a user opens a terminal it will be in base env (if they followed anaconda install instructions), and if they type spyder to launch the IDE, it will automatically use the MNE environment for the spyder internal console and they won't have to think about it, it should just work.

What do you think about the idea of creating a standalone "MNE" installer, which creates a conda installation that's independent of other Python installs on the system, and ships with a ready-to-use Spyder?

I am pessimistic that it will work. Even if it works out of the box, wait 6-12 months until users want to update MNE-Python (or until we tell them to update in order to fix a bug they're facing or get access to a new feature they want) and there's a non-zero chance that Spyder will stop working for them after the update. I recently spent several hours over the course of two days trying to remotely help a colleague deal with exactly that situation.

[hoechenberger]

many (Python) newcomers already have so much new to learn, and virtual environments just added to this complexity and made the onboarding procedure much harder.

Yes. What I'm suggesting above only requires dealing with environments once, during installation. After that, any time a user opens a terminal it will be in base env (if they followed anaconda install instructions), and if they type spyder to launch the IDE, it will automatically use the MNE environment for the spyder internal console and they won't have to think about it, it should just work.

Ok, got you. Maybe it's worth a shot … still I'm not too happy :(

What do you think about the idea of creating a standalone "MNE" installer, which creates a conda installation that's independent of other Python installs on the system, and ships with a ready-to-use Spyder?

I am pessimistic that it will work. Even if it works out of the box, wait 6-12 months until users want to update MNE-Python (or until we tell them to update in order to fix a bug they're facing or get access to a new feature they want) and there's a non-zero chance that Spyder will stop working for them after the update. I recently spent several hours over the course of two days trying to remotely help a colleague deal with exactly that situation.

My idea would be to ask them to uninstall the currently installed version, and install the new one (using the updated installer). So they wouldn't have to fiddle with their environment at all… This is how things are handled with PsychoPy, and most beginners seem to be quite happy with it.

[hoechenberger]

I recently spent several hours over the course of two days trying to remotely help a colleague deal with exactly that situation.

Care to elaborate a little where things went wrong? (if you ever managed to figure it out?)

[drammock]

I recently spent several hours over the course of two days trying to remotely help a colleague deal with exactly that situation.

Care to elaborate a little where things went wrong? (if you ever managed to figure it out?)

In this case it had something to do with it being an older Mac... this issue which also bit @cbrnr a while back I think.

[hoechenberger]

In this case it had something to do with it being an older Mac... this issue which also bit @cbrnr a while back I think.

Interesting! Well well well… wouldn't have happened with conda-forge, which doesn't use MKL! ;)) No but seriously, super annoying!

[cbrnr]

Actually, the problem was not MKL. They (accidentally) enabled the AVX flag, which broke NumPy on all computers with CPUs that didn't support this feature.

On topic: please let's not create a separate standalone installer. What's wrong with pip install mne? That's the default and most Pythonic way to install packages. I've been using it since forever and I never had any issues. Granted, I don't use all the bells and whistles (e.g. VTK), but even that seems to work out of the box (except for the recent issue with VTK 9 on macOS, but I'm optimistic that we can solve this on our end).

[hoechenberger]

On topic: please let's not create a separate standalone installer. What's wrong with pip install mne? That's the default and most Pythonic way to install packages. I've been using it since forever and I never had any issues. Granted, I don't use all the bells and whistles (e.g. VTK), but even that seems to work out of the box (except for the recent issue with VTK 9 on macOS, but I'm optimistic that we can solve this on our end).

I'm not suggesting to get rid of this standard way of installing things. I'm just wondering how to make things easier for new users… Before they can pip install anything, they need to get Python up and running. And then, an IDE. It's complicated for non-developers.

[cbrnr]

I don't think this is true - installing Anaconda and then pip install mne is not a big problem for newbies. The most important dependencies are already installed (including Spyder). I've been teaching this method for several semesters now, and the only major complaint I've heard is that the separation between conda and pip seems to be difficult to grasp (and I agree). But nothing that cannot be explained in a how to install document.

[drammock]

@cbrnr, quoting myself from above, this is why even the simple pip install mne is problematic if users prefer Spyder:

Even if it works out of the box, wait 6-12 months until users want to update MNE-Python (or until we tell them to update in order to fix a bug they're facing or get access to a new feature they want) and there's a non-zero chance that Spyder will stop working for them after the update.

To my mind the right solution is to use an IDE that isolates its dependencies from the dependencies of MNE-Python. Perhaps @hoechenberger can re-direct his efforts creating an installer toward contributing to the Spyder project so that it works the way we think it should (either adding first-class env support, or packaging a proper binary for every platform)?

[cbrnr]

Updating MNE means pip install -U mne, this has never broken my Spyder env.

[hoechenberger]

Perhaps @hoechenberger can re-direct his efforts creating an installer toward contributing to the Spyder project so that it works the way we think it should (either adding first-class env support, or packaging a proper binary for every platform)?

Maybe the first question we need to discuss is: is Spyder the right choice? Or are there other viable alternatives out there? (I know of none, but …)

[cbrnr]

I think Spyder is pretty good for beginners or people coming from MATLAB. It's also preinstalled with Anaconda.

[SophieHerbst]

Hi! Just to pitch in from the user perspective:

• +1 for recommending an IDE, with good documentation on how to set up (spyder works well for people coming from Matlab, I haven't tried PyCharm)
• have one well-documented routine for installation, as simple as possible, robust across operating systems, and ideally not changing with new releases
• You have to take into account that many people in CogNeuro do not know much about conda environments / python packages / let alone working from a terminal, and they already have a lot to learn when getting started with M/EEG analyses.
• Advice for more advanced users can always be given, but they have a higher chance of figuring things out anyways.

[SophieHerbst]

That said, I am in favour of a dedicated mne environment (after re-installing anaconda 3 times in the last 2 days), but it should come with all needed packages and well explained how to handle it.

[cbrnr]

I have a short article on how to set up Python for EEG/MEG analysis. I don't think that it is overly complicated. It uses Anaconda with no additional environments, and results in Spyder plus MNE - i.e. a working environment. From my experience, psychology students have no problems following these instructions.

[SophieHerbst]

Indeed, it is very didactic! Would be very helpful to have such documentation on the mne installation website. Combined with the environment file that gives you all the packages at once

[agramfort]

I tell new comers to use VS Code these days. Python support is excellent.

[cbrnr]

Spyder is still a good place to start. @SophieHerbst my point is also that you don't need an environment file because pip install mne is all that's needed to get a fully functional MNE dev env. Many people won't need optional features such as coregistration, so I don't see the point in installing everything. A dedicated section in the docs could describe what's necessary to get everything.

[hoechenberger]

I tell new comers to use VS Code these days. Python support is excellent.

Are those Python / programming beginners?

I still feel it's difficult to set up and to navigate, and I'm not sure it's very beginner friendly as it heavily relies on seemingly odd keyboard shortcuts (Cmd-Shift-P, anyone?) Also Python documentation is often times not rendered properly :( And 12345 other minor quirks I encounter during daily use, but they mostly concern my development work and probably wouldn't affect ordinary users so much.

[drammock]

@cbrnr:

Updating MNE means pip install -U mne, this has never broken my Spyder env.

that is good to hear. But it is not a guarantee as long as Spyder and MNE both depend on some of the same packages and are installed into the same environment. This is why I made the suggestion above that we at least consider advising users to follow Spyder's recommendations for such cases (install Spyder and MNE into separate environments, and use Spyder settings to force it to use the MNE environment in its embedded consoles).

The downside to this is that it slightly complicates updating MNE (whether to next stable or to current master, both of which options we should support, since many users are unwilling to wait 1-6 months for the next stable release in order to make use of a bugfix or new feature that affects their analysis). Updating would now require activating the mne environment first, and if users forget to do that, they'll end up with different versions of MNE in their base and mne environments... OK, I think I've talked myself out of that solution :frowning_face:

[hoechenberger]

I have a short article on how to set up Python for EEG/MEG analysis. I don't think that it is overly complicated.

It's well-written indeed, nice work!

Since you're eventually recommending conda-based Python distributions, I'm wondering if we shouldn't simply put some effort into fine-tuning the mne recipe on conda-forge; that way, users would be able to simply run conda install -c conda-forge mne spyder and be all set…

[cbrnr]

It's funny that I recommend conda but I don't use it myself, but especially for beginners and people on Windows it really is a good solution. However, this is only true if you stay in the base env and use the defaults channel. You are suggesting to install from conda-forge, so this would have to go into a new env - which is probably something we'd want to avoid.

So far, pip install mne is the easiest way to get base MNE in a default base conda env IMO. Of course some optional deps are missing, but like I said I think many people won't need those extra packages, and we could address these in a separate step (ideally based on the first step). I don't think it will involve that many steps, and if we don't use an environment file we could also pip install something --no-deps.

[hoechenberger]

Going off-topic, but since @agramfort suggested VS Code: they implemented a new language server that is supposed to improve the Python experience: https://devblogs.microsoft.com/python/announcing-pylance-fast-feature-rich-language-support-for-python-in-visual-studio-code/ I will explore this a bit.

[hoechenberger]

However, this is only true if you stay in the base env and use the defaults channel.

I don't understand the reasoning behind that, why is this only true if you stay in base? I think there's even discussions on how to make base something of a read-only thing because users tend to break it all the time… I try to avoid installing anything into base at all costs. Do you mean to say that the added complexity of using environments is problematic? (I would agree)

[SophieHerbst]

@cbrnr My point is that the novel user won't know which package will be needed for what, so if she just pip installs mne, she will later encounter errors (module not found) that she needs to understand can be fixed by installing the respective module. -> this can be fixed by a good documentation, explaining what each package is needed for, and how to get it

However, I find it convenient to have a routine that allows me to get all needed packages at once, and not care about it later.

People who use the developers version likely have different needs, and can use different routines.

As for the separate environment, I see the point that it can create additional confusion, but it seems having everything in base easily creates a mess, so here I would go for separation, but well documented (like in @cbrnr's blog post).

[hoechenberger]

However, I find it convenient to have a routine that allows me to get all needed packages at once, and not care about it later.

Couldn't agree more!

[cbrnr]

Wait until you want/need to upgrade - you will have to care about it again. Packaging is not trivial, but the fewer packages we depend on, the easier it will get. Installing everything (the environment file also contains dev packages that users won't need such as the various pytest packages) will absolutely make that more difficult.

[hoechenberger]

Wait until you want/need to upgrade - you will have to care about it again.

That's why I'm very much in favor of providing a self-contained standalone bundle with all dependencies. And users don't update by fiddling with the Python env, but by removing the previously installed standalone version and installing the new one.

[hoechenberger]

Installing everything (the environment file also contains dev packages that users won't need such as the various pytest packages) will absolutely make that more difficult.

This is trivial to fix: we provide separate env files for users and devs. I'm actually surprised we're not doing this already.

[cbrnr]

I remember discussing this once, didn't we also want to provide an env for MNE base? So we could split it up into base, full, and dev?

[cbrnr]

That's why I'm very much in favor of providing a self-contained standalone bundle with all dependencies. And users don't update by fiddling with the Python env, but by removing the previously installed standalone version and installing the new one.

If by standalone you mean environment then :+1:!

[drammock]

Separating the questions:

a) How should users install Python? It's my impression that there's agreement that conda is the way to go here: the only way to get some approximation of the same software environment across all platforms. There is still potentially some latitude here in recommending Anaconda vs Miniconda (or possibly Miniforge).

b) How should users install MNE-Python? Options here are environment.yml (defaults channel), a new conda-forge based environment.yml, or only pip (this might be less dependency-conflict-prone if starting from Miniconda rather than Anaconda?)

c) If using conda, should they install into base or a dedicated mne environment? Personally I'm in favor of a separate environment, to avoid conflicts between Spyder dependencies and MNE dependencies.

Summarizing some concrete options:

1. Anaconda + environment.yml using base environment and defaults channel (our current approach).

   • pro: already in place, no work to change it.
   • con: Potential for Spyder & MNE dependency clashes. (NB: this is not hypothetical; several users have experienced this).

2. Same as 1, but using conda-forge channel (as proposed in #7946).

   • pro: Avoids installing PyQt5 by both conda and pip
   • con: amounts to recommending newer (less-well-tested) versions of our dependencies, to users who are less experienced/comfortable fixing dependency problems when they arise.
   • con: Potential for Spyder & MNE dependency clashes.

3. Same as 1, but using separate mne environment (with Spyder in base; Spyder's recommendation).

   • pro: no more dependency conflicts with IDE.
   • con: Extra 1-time setup step in Spyder GUI to set a different interpreter for internal consoles.
   • con: Easy for user to erroneously install MNE into base when upgrading. Could be mitigated by:
     • auto-activating mne environment in their .bashrc file or permanently setting CONDA_DEFAULT_ENV=mne, and
     • aliasing spyder in their .bashrc file so that they don't need to have base env activated in order to launch it (this is the approach I take with R, so that I get one conda-managed R installation available across all my different python envs).

4. Miniconda + pip

   • pro: Avoids installing PyQt5 by both conda and pip
   • con: Potential for Spyder & MNE dependency clashes?

Please feel free to edit this comment (or reply if that's easier) to add options I missed, or refine the pro/con assessments.

[hoechenberger]

Thanks for your work, @drammock!

b) How should users install MNE-Python? Options here are environment.yml (defaults channel), a new conda-forge based environment.yml, or only pip (this might be less dependency-conflict-prone if starting from Miniconda rather than Anaconda?)

I'd like to once again pitch a fourth option, which is providing an installer that includes a full-fledged working environment with all dependencies, like the PsychoPy standalone distributions.

[cbrnr]

I'm -100 for a separate installer. First, creating this for Windows and Mac is a tremendous amount of work. Second, I'm afraid if this will be the recommended method, installing MNE via pip will become less important and eventually won't work because there is a working standalone installer. PsychoPy is an example of such a behavior, although it has become easier to pip install recently. I would really like MNE to stay a proper Python package that can be pip installed.

[drammock]

I would really like MNE to stay a proper Python package that can be pip installed.

agreed

[agramfort]

Agreed

[hoechenberger]

First, creating this for Windows and Mac is a tremendous amount of work.

It's not if you use the right tools. I just built one for macOS using constructor in 15 min, you may download it from https://drive.google.com/file/d/12TZ_JXBzxnRWuJVtKsOn5M7aYuZ15aRr/view?usp=sharing

It's based on the conda-forge MNE-Python package and by default installs MNE to ~/mne-python. After installation you can simply open a terminal,

cd ~/mne-python
./bin/spyder

and you have a working IDE.

And even more, you have an actual Python (conda) installation you can use to update / install packages.

Second, I'm afraid if this will be the recommended method, installing MNE via pip will become less important and eventually won't work because there is a working standalone installer.

Nobody is going to deprecate PyPI packages unless we do…

PsychoPy is an example of such a behavior, although it has become easier to pip install recently.

I have to admit PsychoPy is a horrible example for packaging best practices. Yet, the standalone package made it so much more approachable for beginners.

I would really like MNE to stay a proper Python package that can be pip installed.

Yes absolutely. I think you're creating a false dichotomy here. Having a standalone installer doesn't render the PyPI package unusable or less important. I, personally, would always install from PyPI or via conda...

[cbrnr]

I'm just afraid that the PyPI package might be demoted to second class if everything works so great with the standalone installer. Like I said, devs might be inclined to "just fix a problem in the standalone installer" and leave the PyPI package in a less than ideal state. It's hard to say what will happen in the long run if there are two MNE packages to maintain.

Regarding PsychoPy, I get the point why a standalone installer made it so much more approachable - but I think this was in large parts due to the fact that PsychoPy used to be almost impossible to install via pip. I'd have put more resources into making the PyPI package nice and clean instead of working around the problem by creating a standalone installer. Here are some issues with the standalone version: for Python beginners, it's really hard to grasp that PsychoPy standalone ships its own Python and packages, and therefore their main (Anaconda) Python has no access to these packages. Also, using Spyder to develop PsychoPy paradigms is much more complicated if PsychoPy ships its own Python.

Currently, things have improved a lot, and pip install psychopy --no-deps already gives you a basic PsychoPy installation already.

[hoechenberger]

Thanks for sharing your thoughts, @cbrnr!

The installers created via constructor deploy a full-fledged conda-based Python distro, which would avoid some of the problems you brought up.

But since the current consensus seems to be that a standalone package is not really desirable, I'd like to come back to one of @drammock's proposals:

• Same as 1, but using conda-forge channel (as proposed in #7946).

  • pro: Avoids installing PyQt5 by both conda and pip
  • con: amounts to recommending newer (less-well-tested) versions of our dependencies, to users who are less experienced/comfortable fixing dependency problems when they arise.
  • con: Potential for Spyder & MNE dependency clashes.

I think all of these issues can be addressed. My perception is that they arise because currently, we have a single environment.yml file for developers, CI, and end users. Even more, the installation instructions suggest to use the very same environment.yml for development and stable installs (see https://mne.tools/stable/install/mne_python.html#installing-mne-python-and-its-dependencies – the link points to https://raw.githubusercontent.com/mne-tools/mne-python/master/environment.yml)

Let's look at your concerns individually:

• con: amounts to recommending newer (less-well-tested) versions of our dependencies, to users who are less experienced/comfortable fixing dependency problems when they arise.

• If we provide an environment file specifically for end-user installations, we could pin package versions to ones that are known to be working properly. This environment file would get updated at least once or twice a year, with each new MNE minor release.
• Also I would like to make the point that you would have the same issue with a purely pip-based install.
• Dependency problems should be of little concern when using a user-oriented, full-fledged environment file to begin with. What I'm trying to say is that the environment's package contents may very well be quite "extensive" to cover most (ideally: ~all) of potential use cases. So what if this ends up eating 4 GB of disk space – the important thing is that it works and provides users with everything they need. If we deliver something that works well from the start, users won't need to fiddle with package installations, which will effectively avoid dependency problems.

• con: Potential for Spyder & MNE dependency clashes.

• I'm very confident we can get this sorted out. The current issue is related to different PyQt5 naming schemes, but if one installs all MNE dependencies -- and, especially all Qt-dependent packages -- via conda-forge before running pip install mne --no-deps, all should be fine.

Lastly, I think it's worth trying to decide whether we would like users to be able to try out development versions too, or whether sticking to releases is the way to go for the majority of users. If the priority is delivering a usable "stable" release of MNE, I think we should (re)direct some effort to the conda-forge package, which already works quite well, but still has some issues with Mayavi (which will soon not be needed anymore anyway, as we're moving everything 3D to pyvista), and VTK (currently only VTK 9.0.0 is available on conda-forge, and nobody seems to be really looking into why 9.0.1 isn't building)

[cbrnr]

That's a good suggestion @hoechenberger!

[drammock]

I'm very confident we can get this sorted out. The current issue is related to different PyQt5 naming schemes, but if one installs all MNE dependencies -- and, especially all Qt-dependent packages -- via conda-forge before running pip install mne --no-deps, all should be fine.

I don't think the core issue is related to different PyQt naming schemes. It's related to the fact that the IDE depends on some of the same packages as MNE-Python does. And as long as MNE-Python continues to be under heavy development, we need the flexibility to be able to update our dependency version requirements without having it break user's IDEs. Put more plainly, we shouldn't be prevented from using package>=4 simply because Spyder is still pinned at package==3.9. And as long as MNE and Spyder are installed into the same environment, that is a risk. This is why I'm in favor of my option 3 above: it puts the IDE and our software into separate enviroments, and this problem goes away.

Lastly, I think it's worth trying to decide whether we would like users to be able to try out development versions too, or whether sticking to releases is the way to go for the majority of users.

Again, we're frequently dealing with users who find a bug or request a feature, and who want to use it right away (not wait 1-6 months to finish their analysis). I don't think it's the majority of our users, but it's a common enough request that I think we should at least try to make it easy-ish for people to switch from stable to current master (and back). Currently it's possible by passing the github zipball URL to pip, or passing a specific released version number to pip if you want to switch back to stable. I would like to keep it so that it's still that easy.

In principle I'm not opposed to having a few different environment files for different use cases --- it seems like we're already at least trying out that approach for the pyvista notebook server setup. But I think there's value in having setup instructions for python-novice users that use the standard anaconda installer --- people seem to like the Anaconda Navigator GUI (rather than, say, having to open a terminal and type spyder to launch their IDE), and it gives them easy access to launching notebooks without a terminal too. That would mean sticking with a base environment that uses defaults channel --- which is fine for running Spyder, and if mne goes into a separate environment anyway, it could still use conda-forge there if we wanted.

I'm installing some windows VMs today, so soon I'll be able to test out the idea of putting MNE and Spyder into separate environments and seeing how it works via the Anaconda Navigator GUI (I already know it works on Linux if you're launching spyder from terminal).

[hoechenberger]

@drammock Everything you said makes a lot of sense to me.

Does the Anaconda navigator also support installing packages via pip?

If not, we could look into ways to build & publish nightly conda-forge packages?

I'm installing some windows VMs today, so soon I'll be able to test out the idea of putting MNE and Spyder into separate environments and seeing how it works via the Anaconda Navigator GUI (I already know it works on Linux if you're launching spyder from terminal).

Sounds great, I'm curious to hear how it went!

[agramfort]

I also like the idea of keeping IDE and mne in separate environments.

also just as a disclaimer when I teach mne and people do not need any 3D I tell students to do:

pip install numpy scipy matplotlib mne

and it just works. So technically mne can be used with a very minimal environment. Maybe we don't say this enough...