Use Pixi in macOS-intel CI

[scott-huberty]

I'm exploring the feasibility of using Pixi to resolve the virtual environment and run tests specifically for the MacOS Intel CI, which currently uses Mamba to create the virtual environment.

My initial strategy was to just to do pixi init --import environment.yml, so that we can leverage our already defined YAML config file to pull in all the necessary dependencies, as well as configuring prefix-dev/setup-pixi to automatically activate our virtual environment, so that we can run commands like pytest etc without having to prepend pixi run everywhere for the pixi CI...

Unfortunately the only way I could get this to work was to disable use of a login shell.. Which of course makes all the condo-like CI's fail!!

[tsbinns]

Hey @scott-huberty, looking at the current diff I noticed you're setting up pixi without activating the env, initing with environment.yml, then setting up again with env activation.

Found when switching to uv for the old job that the env can be activated at setup with a given Python ver and then have the required packages installed in github_actions_dependencies.sh:

mne-python/.github/workflows/tests.yml

Lines 157 to 165 in 8dd298f

	- uses: astral-sh/setup-uv@v7
	with:
	version: ">=0.9"
	activate-environment: true
	cache-dependency-glob: |
	**/pylock.ci-old.toml
	python-version: ${{ matrix.python }}
	if: matrix.kind == 'old'
	- run: bash ./tools/github_actions_dependencies.sh

Wondered if a similar thing could work for pixi rather than needing 2 setups. Haven't looked through diffs for all commits, so apologies if you tried this already.

[scott-huberty]

Ok things are finally making progress! After a few pair programming sessions with @drammock , we are able to at least run the python/pytest commands in the Pixi job, without making changes that break other jobs.

Now, the Pixi job test suite is erroring out with a segfault. My current hypothesis is that, because I built the pixi.toml file from the environment.yaml, we may be hitting the same error that the conda-like jobs hit before #13049 added the 'Fixes for conda' step to tests.yaml.

As previously discussed with @drammock - the right path forward is probably to solve the Pixi environment from our pyproject.toml instead. I will do that next, and see if it resolves the aforementioned segfault error.

[drammock]

@scott-huberty if you incorporate the suggestions here and regen the lockfile (and push it), it should quickly tell us whether the segfault is caused by the pyside/vtk versions

[scott-huberty]

@scott-huberty if you incorporate the suggestions here and regen the lockfile (and push it), it should quickly tell us whether the segfault is caused by the pyside/vtk versions

Confirmed 🙂

[larsoner]

I think it's cleaner and simpler to get the path right in the first place like in mne-tools/mne-bids#1588 rather than prepend conditionally

[drammock]

@scott-huberty regarding frozen:true:

• we know that pixi is unyielding about --manifest-path getting passed a file called pixi.toml
• we should probably assume it will be similarly unyielding about the name of the lockfile
• therefore we should move tools/pixi.toml to tools/ci/macos-intel/pixi.toml
• also move tools/pixi-macos-intel.lock to tools/ci/macos-intel/pixi.lock

Regarding the sequencing of the PATH workaround: I think it just needs to come before github_actions_dependencies.sh (you were correct that github_actions_env_vars.sh doesn't need it)

[larsoner]

Regarding the sequencing of the PATH workaround: I think it just needs to come before github_actions_dependencies.sh (you were correct that github_actions_env_vars.sh doesn't need it)

I would put it immediately after whatever step is supposed to set it up so subsequent steps have python venv configured correctly, as it's really a fix for the interaction between that action and our use of -l. So I think where it is now ( - name: Workaround for macOS behavior on login shells) looks reasonable

[drammock]

@scott-huberty https://github.com/mne-tools/mne-python/actions/runs/25123755805/job/73631753409#step:9:60

the path we're adding to PATH is the wrong path