On macOS, the executable is installed into /Users/runner/micromamba-bin/micromamba, which is not in $PATH on macos-latest (M1 runners) but is on macos-12 (Intel architecture). This appears to be the root cause of surprising behavior i.e. commands like which micromamba fail. Here is a reproducing workflow: https://github.com/mattwthompson/micromamba-path-reproduction/actions/runs/10891923866/workflow
Credit to @ethanholz for trying a bunch of things that resulted in narrowing this down.
We can work around this by setting micromamba-binary-path but this doesn't seem like it should be required. In fact, I didn't have to set this option in the past. This behavior changed sometime around Friday of last week (9/13 or 9/14) for reasons I'm unable to pin down:
On macOS, the executable is installed into
/Users/runner/micromamba-bin/micromamba
, which is not in$PATH
onmacos-latest
(M1 runners) but is onmacos-12
(Intel architecture). This appears to be the root cause of surprising behavior i.e. commands likewhich micromamba
fail. Here is a reproducing workflow: https://github.com/mattwthompson/micromamba-path-reproduction/actions/runs/10891923866/workflowCredit to @ethanholz for trying a bunch of things that resulted in narrowing this down.
We can work around this by setting
micromamba-binary-path
but this doesn't seem like it should be required. In fact, I didn't have to set this option in the past. This behavior changed sometime around Friday of last week (9/13 or 9/14) for reasons I'm unable to pin down:mamba
itself (1.5.9 is used)Am I doing something wrong here? Was I doing something wrong before?