valid micromamba installation not found by openff utils

[atravitz]

Currently, micromamba can be installed and run correctly even if its installation location is not in the user's $PATH: mamba-org/mamba#2577

This leads to a discrepancy where the micromamba installation is completely valid, but then openff fails with a openff.utilities.exceptions.CondaExecutableNotFoundError.

I would expect that if micromamba (or conda, mamba, etc.) runs successfully, that openff should be able to detect it as well. Can https://github.com/openforcefield/openff-utilities/blob/main/openff/utilities/provenance.py be updated to be more robust to this, and less dependent on searching for specific installation locations?

[j-wags]

This is a really interesting proposal. I'm trying to think of the case where a user is in a properly initialized micromamba env, but doesn't have micromamba in their path, are there other environment variables we can look at to determine where the micromamba executable is?

[mattwthompson]

Some of the install routes don't play nicely with subprocessing. (Less likely, but possible, is that find_executable isn't wired up to handle the shell functions.) The four supported environment managers are frustratingly implemented in that they're shell functions, not commands. (pixi, for which support here is in process, doesn't suffer from this IIUC.) I'm not sure how to work around this except for an added clause to look in ~/.local/bin/micromamba on some platforms?

I think brew install micromamba puts it in /usr/local/bin which, after shell magic, is accessible in normal PATH configurations. I'm fairly confident the action ends up with the same behavior but I'm having trouble pulling up the receipts.

---

All this being said - I'd love to not make a subprocess call at all, but I don't know any other way to access the list of installed packages. The last time I tried to find a uniform Python API that mimics these CLIs, there wasn't one. And we unfortunately use a few non-Python packages so we can't just query a bunch of __version__ (nor would we want to import everything just to get an environment check). I don't know your use case, but provenance shortcuts might be smaller and safer (openforcefield/openff-toolkit#1865 comes to mind, but we had to go the opposite direction because of an upstream bug).

[mikemhenry]

I am not sure yet how to do it, but I do think making find_executable aware of shell functions would resolve this issue.

[mikemhenry]

Also, should this trigger an exception? Perhaps a warning about being unable to check package versions would be better.

[mattwthompson]

This has become too much work compared to the benefit provided, I'm just going to have it warn and return an empty dictionary when something goes wrong.

[mikemhenry]

Thanks @mattwthompson!

[cyrushu]

If you do conda install conda within your environment, you can pass the find_executable function

[mikemhenry]

Yes, installing conda or mamba into an environment will fix this (for future people running into this error).

[mattwthompson]

Look for this in the next release, probably version 0.1.13 and sometime on the week of December 2nd

(I don't make releases on Fridays and next week is a holiday week in which many of us are half-off.)