Culling packages

[matthew-brett]

Cull packages specific to MNE.

Cull some visualization packages (VTK, pyvista etc).

Cull some development packages (these can be installed later via the command line).

Add pyreadstat (for SPSS etc import into Pandas) and nbclassic (for users who prefer the classic Jupyter interface).

[autofix-troubleshooter]

Hi! I'm the autofix.ci troubleshooter bot.

It looks like you correctly set up a CI job that uses the autofix.ci GitHub Action, but the autofix.ci GitHub App has not been installed for this repository. This means that autofix.ci unfortunately does not have the permissions to fix this pull request. If you are the repository owner, please install the app and then restart the CI workflow! 😃

[drammock]

@munkm can you take a look at the list of installed packages (and the ones being removed) to see if this environment would be suitable for your classes/needs?

@matthew-brett build actions are succeeding but test actions are all failing. We should try to sort that out in this PR I think.

[munkm]

All of the dependencies that I would use for my class exist in the new version of the installer! Thank you for adapting this! I made a couple of minor comments unrelated to the packages I'd use in my class, but are relevant to the PR.

I think it's probably outside of the scope of this PR, but wanted to point out that there's a few MNE references up through line 50 that we'd probably want to update after this PR goes in. They include:

• prefix paths
• installer names and scripts

[munkm]

Both VTK and Mayavi were removed as dependencies.

Suggested change

	- pyside6 =6.8.2 # allow_outdated, PyVista (VTK 9.3.1) and Mayavi
	- pyside6 =6.8.2

[drammock]

this probably means that we can/should bump the pin? I'm guessing that the comment is used in tests that check that the pins reflect the most current available version, so if we simply remove it without bumping the pin, it will cause a test failure.

[matthew-brett]

I dropped Qt stuff completely - should it come back?

[munkm]

I noticed a couple more places I can see MNE in these updated files. The main place I noticed was in installers, but the check_installation.sh file refers to some things that probably need to be updated too.

• here this test refers to $MNE-MACHINE and also refers to an install path that was changed in the updated construct.yaml.
• here we have some MNE references and paths
• here is another path that probably should be updated
• MNE install prefixes

[matthew-brett]

Conda issue : conda/conda#14884

Meanwhile, trying fix to manually overwrite CONDA_EXE in our scripts.

[matthew-brett]

1c3bb07 works around the problem for our purposes.

@larsoner - you probably also need the fixes in d6619e9 - the code was looking for all Python installations and showing the one that is last on the path.

[matthew-brett]

@drammock - I think this one is ready to merge now. We still need to sort out Apple certificate signing - see #10 - but that can wait for another PR.

[drammock]

OK tested fairly thoroughly on Linux. Some notes:

1. menu icons install into the "Other" folder. I think we can fix this later (there are I think built-in categories for "science" and "Development", either of these would be better).

2. I'm leaving some TODOs in the Makefile for folks building the package on Windows (again, can be added later).

3. To make it easy for others to develop / remix / build this installer locally, I think we should add either a Makefile recipe like this:

   build-environment:
   @conda create -n sp-installer "python=3.11" conda-build conda-verify constructor joblib threadpoolctl && \
   conda activate sp-installer

   ... or put a dev section in project.optional_dependencies of pyproject.toml that will install the necessary build deps. (can be done later).

I'll open separate issues for each of these suggestions.

[drammock]

IIRC this logo ended up not looking super good in the macOS installer (shoved too far into the corner). mentioning as a TODO for later.

[drammock]

Almost there I think! But:

• Windows build is failing (I think because of removing --no-test):

  https://github.com/scientific-python/installer/actions/runs/15333037607/job/43144153017?pr=3#step:6:425

  @matthew-brett do you have any cycles available to debug? If not, we could restore --no-test for just the Windows CI job, and open an issue to chase it down later (assuming that the .exe does in fact work for you).

• something is awry with the CI config:

  

[matthew-brett]

It looks like Windows isn't running the tests in any case - see https://github.com/scientific-python/installer/actions/runs/15333037607/job/43144153017?pr=3#step:6:441

[drammock]

It looks like Windows isn't running the tests in any case - see https://github.com/scientific-python/installer/actions/runs/15333037607/job/43144153017?pr=3#step:6:441

Caveat: I don't fully understand the conda build process. But: IIUC --no-test just prevents entries in test:commands (in sp-installer-menu/meta.yaml) from being run (cf third bullet-point here). AFAICT testing of the menu installer is being run, see:

subprocess.CalledProcessError: Command '['C:\Windows\system32\cmd.exe', '/d', '/c', 'C:\a\installer\installer\conda-bld\sp-installer-menu_1748550987689\test_tmp\conda_test_runner.bat']' returned non-zero exit status 1

https://github.com/scientific-python/installer/actions/runs/15333037607/job/43144153017?pr=3#step:6:466

which references a .bat file, not a .sh (that said, not sure where the "ignoring .sh file" warning is coming from).

Additionally, I also spotted this line:

WARNING: Importing conda-verify failed. Please be sure to test your packages. conda install conda-verify to make this message go away.

https://github.com/scientific-python/installer/actions/runs/15333037607/job/43144153017?pr=3#step:6:380

which makes me think we should add conda-verify to the CI env.

[drammock]

something is awry with the CI config

this is probably a non-issue; the windows build was passing on 6dc0750 and the $MATRIX_OS entry was replaced by 2 entries (windows-2019 and windows-2022)