Should CONDA_PREFIX be set by default?

[meridionaljet]

When using micromamba outside a container, it sets CONDA_PREFIX to the environment's root directory whenever an environment is active, including base. However, when using the mambaorg/micromamba:latest image with micromamba 1.5.8, CONDA_PREFIX is not set inside the container, even though the base environment is activated by default. This is leading to issues when using software that rely on this variable being set, such as uv: https://github.com/astral-sh/uv/issues/2862

Am I correct in interpreting that CONDA_PREFIX should always be set when an env is active? If CONDA_PREFIX being unset in this docker image is correct behavior, it would be helpful to understand why so that maintainers of uv and other software can accommodate mamba environments.

[wholtz]

Hi @meridionaljet -- thanks for reporting this. I am not able to reproduce what you are seeing:

docker run -it --rm mambaorg/micromamba:1.5.8 /bin/bash -c 'echo $CONDA_PREFIX'
/opt/conda

What do you get when running that command?

[meridionaljet]

@wholtz I apologize, I have come to realize that CONDA_PREFIX is specifically unset during build time, because the base environment is not activated until the base image entrypoint is run. I was encountering problems with something like:

Dockerfile:

FROM mambaorg/micromamba:latest
ENV PATH="/opt/conda/bin:$PATH"
RUN micromamba install -y -n base -c conda-forge uv
RUN uv pip install sqlalchemy

Running docker build . results in:

 => ERROR [3/3] RUN uv pip install sqlalchemy                                         0.2s
------
 > [3/3] RUN uv pip install sqlalchemy:
0.153 error: Failed to locate a virtualenv or Conda environment (checked: `VIRTUAL_ENV`, `CONDA_PREFIX`, and `.venv`). Run `uv venv` to create a virtualenv.
------
Dockerfile:4
--------------------
   2 |     ENV PATH="/opt/conda/bin:$PATH"
   3 |     RUN micromamba install -y -n base -c conda-forge uv
   4 | >>> RUN uv pip install sqlalchemy
   5 |
--------------------
ERROR: failed to solve: process "/usr/local/bin/_dockerfile_shell.sh uv pip install sqlalchemy" did not complete successfully: exit code: 2

Because no environment is activated and uv is looking for one. I apparently cannot try to activate the base environment during the build either. If I include RUN micromamba activate base in the Dockerfile, I get stuff like:

 > [4/5] RUN micromamba activate base:
0.189 critical libmamba Shell not initialized
0.189
0.189 'micromamba' is running as a subprocess and can't modify the parent shell.
0.189 Thus you must initialize your shell before using activate and deactivate.
0.189
0.189 To initialize the current  shell, run:
0.189     $ eval "$(micromamba shell hook --shell )"
0.189 and then activate or deactivate with:
0.189     $ micromamba activate
0.189 To automatically initialize all future () shells, run:
0.189     $ micromamba shell init --shell  --root-prefix=~/micromamba
0.189 If your shell was already initialized, reinitialize your shell with:
0.189     $ micromamba shell reinit --shell
0.189 Otherwise, this may be an issue. In the meantime you can run commands. See:
0.189     $ micromamba run --help
0.189
0.189 Supported shells are {bash, zsh, csh, xonsh, cmd.exe, powershell, fish}.

And the recommended remedy eval "$(micromamba shell hook --shell ) doesn't seem to help.

Interestingly, using software like uv works fine if I fake CONDA_PREFIX by setting it to /opt/conda at build time before using uv.

If this is all behaving exactly as expected, then I apologize. If software like uv cannot expect to find an activated environment when used in a docker build process, then I can take that knowledge back to the maintainers.

[wholtz]

Please read our documentation on activating a conda environmental during docker build ...: https://micromamba-docker.readthedocs.io/en/latest/quick_start.html#running-commands-in-dockerfile-within-the-conda-environment

[meridionaljet]

Thank you - I apologize for missing this.