Mamba 2.0 - installing in the base env without activation

[SylvainCorlay]

With Conda (and Mamba 1.x), running conda install foobar or mamba install foobar will install foobar in the base environment when no environment is activated. However, micromamba and mamba 2.0 will complain that no prefix is specified.

This is the root cause for the current failure when updating repo2docker to the latest rc of mamba 2.0.

I believe that we should support this behavior, as it will generally be expected from conda users who don't use environments much.

A possible approach would be to

1. Set up the mamba package so that the root prefix is set to the installation prefix of mamba.
2. Always default to the root prefix when installing a package (either for both micromamba and mamba, or just for mamba, behind a flag).

[SylvainCorlay]

A first issue regarding Item 1 (on setting up the mamba package so that the root prefix is set to the installation prefix of mamba), is that running mamba shell init from the installed mamba package (with 2.0.0rc4) populates bashrc with:

# >>> mamba initialize >>>
# !! Contents within this block are managed by 'mamba shell init' !!
export MAMBA_EXE='/home/sylvain/micromamba/envs/mamba/bin/mamba';
export MAMBA_ROOT_PREFIX='/home/sylvain/micromamba';
__mamba_setup="$("$MAMBA_EXE" shell hook --shell bash --root-prefix "$MAMBA_ROOT_PREFIX" 2> /dev/null)"
if [ $? -eq 0 ]; then
    eval "$__mamba_setup"
else
    alias mamba="$MAMBA_EXE"  # Fallback on help from mamba activate
fi
unset __mamba_setup
# <<< mamba initialize <<<

The fact that MAMBA_ROOT_PREFIX is set to HOME/micromamba is obviously a bug.

[Hind-M]

The fact that MAMBA_ROOT_PREFIX is set to HOME/micromamba is obviously a bug.

I don't get why this is a bug. Do you mean that it should be HOME/mamba instead?
IIRC HOME/micromamba is only used if it already exists (from previous usage of micromamba 1.x).