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]

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: ...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.

Hey @tsbinns no worries, and that sounds exactly like what I want to do with pixi (declare a venv without installing everything eagerly), but IRRC, In my quest to just "get it working", it seemed that by default setup-pixi tries to immediately create and resolve the environment, which requires a pre-existing pixi.toml to exist in the repo (which we don't have).

Since my strategy here is to create the pixi.toml via pixi init --import environment.yml, I just needed to get the pixi command to PATH, Which is why I ended up with the initial call to setup-pixi with run_install: False -> followed by pixi init to create the pixi.toml, and then finally ran setup-pixi with run_install: True to actually resolve the environment. 😵‍💫

I agree that ideally we should only have to run setup-pixi once.. I'll take a closer look at your PR to see if I can take some inspiration here!

[tsbinns]

Hey @tsbinns no worries, and that sounds exactly like what I want to do with pixi (declare a venv without installing everything eagerly), but IRRC, In my quest to just "get it working", it seemed that by default setup-pixi tries to immediately create and resolve the environment, which requires a pre-existing pixi.toml to exist in the repo (which we don't have).

Ah okay, so it's stricter than the uv setup action.

Since my strategy here is to create the pixi.toml via pixi init --import environment.yml, I just needed to get the pixi command to PATH, Which is why I ended up with the initial call to setup-pixi with run_install: False -> followed by pixi init to create the pixi.toml, and then finally ran setup-pixi with run_install: True to actually resolve the environment. 😵‍💫

Got it. But in the end, would we not want a pixi.toml file anyway that would be committed to the repo and (eventually) also contain env info for the other CI jobs?

[scott-huberty]

Got it. But in the end, would we not want a pixi.toml file anyway that would be committed to the repo and (eventually) also contain env info for the other CI jobs?

Yeah if we think that a pixi.toml/pixi table would be helpful for users and other CI's we certainly can do that. In that case, I guess we would need to decide on whether to initialize the pixi toml/table from our pyproject.toml or from our environment.yaml. For the purpose of just swapping out mamba for pixi in this CI with minimal refactoring, I opted to use the environment.yaml file, but it might be better to use the pyproject.toml, as this way the pixi toml/table inherits the dependency groups and such.