As part of the hacks used in conda-lock, we create a fake Conda environment containing just the package metadata in $PREFIX/conda-meta/, and we query this by running micromamba list -p fake-conda-env --json in a subprocess.

The v2 changes have broken this process because micromamba now checks not just for conda packages but newly for pip packages in the PrefixData::load_site_packages function by running python -q -m pip inspect --local.

The problem I'm now having is that load_site_packages expects a python executable to be present in $PREFIX/bin. Moreover, it's this python executable is then used in the python -q -m pip inspect --local command. But in conda-lock's fake environment, we don't have a $PREFIX/bin, so when load_site_packages calls get_python_path the result is an empty string, and I get the following error message:

critical libmamba could not load prefix data: failed to run python command :
      error: The parameter is incorrect.
      command ran:  -q -m pip inspect --local
      env options:("PYTHONIOENCODING", "utf-8") ("NO_COLOR", "1") ("PIP_NO_COLOR", "1") ("PIP_NO_PYTHON_VERSION_WARNING", "1")

Note that /path/to/some/python is missing before -q -m ....

What conda-lock is doing with the fake environment is hacky, and is not the responsibility of libmamba. But I just want to get it running again with v2, so I hope that you consider accepting this patch to allow me to disable the functionality from conda-lock by setting an environment variable. I expect only conda-lock to use this, so I don't think we need to document it.

(Note that I have tried other workarounds such as adding a fake python script to my fake conda environment, but on Windows the which_in helper only seems to detect .exe files and not .bat scripts, so that would require me to compile binaries which is not so viable for a pure Python project like conda-lock. I am open to other suggestions.)

Thanks for your consideration!