Conda executable finding fails on macos-latest with micromamba

[IAlibay]

Been picking up this as an issue across our pipelines, not 100% sure when but it looks like something changed in the last couple of days. This looks to be purely isolated to micromamba (mamba works fine)

See here for CI tests that reproduce the issue: https://github.com/IAlibay/openff-utilities/pull/1

[mattwthompson]

This is legit and unfortunately also crashing all of our testing infrastucture. I have no idea what caused this, but given the lack of recent commits, it's likely something upstream.

We've faced issues before with one of the three binaries (conda, mamba, or micromamba) not being accessible in an action, but that doesn't seem to be what's happening here. It's ... surprising that checking for each binary fails, whereas some symlinks between them might not be.

I don't see any relevant changes in the action image, though it was bumped around the time everything broke for me: https://github.com/mamba-org/setup-micromamba/commits/main/

There's a 2.0 version of the Mamba stack, but that doesn't seem to be what's going on here, either ...

I'll crack open the debugging can and see what comes of this

[mattwthompson]

Nothing obvious changed recently in the os module, by my eye: https://docs.python.org/3/library/os.html

[IAlibay]

the gh actions image for macos-latest changed roughly around that time: https://github.com/actions/runner-images/pull/10603

[mattwthompson]

Whoops yeah I meant to link to that above, my clipboard is more like a roulette wheel at times

I've narrowed it down to os.path.isfile failing in CI, which .... is a surprise. Everything is fine locally:

>>> import os
>>> os.path.isfile("/usr/local/bin/micromamba")
True

[mattwthompson]

Conceivably, this all could be replaced with fewer LOC which just use shutil:

https://github.com/openforcefield/openff-utilities/blob/5b803ebaee28059af313127e9c1857b176d1cd7b/openff/utilities/utilities.py#L136-L151

[mattwthompson]

As a workaround -

Just add mamba or a similar executable to the testing environment

[mattwthompson]

Better workaround!

Add this options to the mamba-org/setup-micromamba action:

        micromamba-binary-path: ~/.local/bin/micromamba

so that it looks something like

    - name: Set up conda environment with micromamba
      uses: mamba-org/setup-micromamba@v1
      with:
        micromamba-binary-path: ~/.local/bin/micromamba
        environment-file: devtools/conda-envs/test_env.yaml
        create-args: >-
          python=${{ matrix.python-version }}

This should work on Ubuntu & macOS runners (Intel & M1). This shouldn't be applied to other actions as it appears to be a quirk with this one only.

Thanks to @ethanholz for finding some quirky behavior that necessitates this band-aid - will be reporting upstream in case we're doing something strange.

[IAlibay]

Amazing, thanks for the work here @mattwthompson !

Do we know if this is limited to how gh actions is doing its thing? I.e. how likely is this to hit users directly?

[mattwthompson]

Do we know if this is limited to how gh actions is doing its thing?

Yes - we think mamba-org/setup-micromamba only, but it could be something more widespread to macOS runners in general. Here is the upstream report: https://github.com/mamba-org/setup-micromamba/issues/224

I.e. how likely is this to hit users directly?

I think very unlikely - this bubbles up from upstream of which micromamba so I don't see a need to update this package.