Micromamba: Cannot activate env because cannot initialize shell cmd.exe (corp env)

[oscar6echo]

Troubleshooting docs

• My problem is not solved in the Troubleshooting docs

Anaconda default channels

• I do NOT use the Anaconda default channels (pkgs/* etc.)

How did you install Mamba?

Micromamba

Search tried in issue tracker

yes

Latest version of Mamba

• My problem is not solved with the latest version

Tried in Conda?

I do not have this problem with Conda, just with Mamba

Describe your issue

The problem takes place in Windows only on a corp config (ie. very constrained and somewhat opaque).

It is impossible to activate an env because it is impossible to initialize shell cmd.exe.

Attempt to initialize shell:

C:\Users\ACORPUSER>micromamba shell init --shell cmd.exe --root-prefix=%MAMBA_ROOT_PREFIX%
cmd.exe already initialized.
Enter admin mode to enable long paths support?: [y/N] N
Aborted.
warning  libmamba Did not enable long paths support.

Attempt to activate env:

C:\Users\ACORPUSER>micromamba activate work4
critical libmamba Shell not initialized

'micromamba' is running as a subprocess and can't modify the parent shell.
Thus you must initialize your shell before using activate and deactivate.

To automatically initialize all future (cmd.exe) shells, run:
    $ micromamba shell init --shell cmd.exe --root-prefix=~/.local/share/mamba
If your shell was already initialized, reinitialize your shell with:
    $ micromamba shell reinit --shell cmd.exe
Otherwise, this may be an issue. In the meantime you can run commands. See:
    $ micromamba run --help

Supported shells are {bash, zsh, csh, posix, xonsh, cmd.exe, powershell, fish, nu}.

Attempt to reinitialize shell:

C:\Users\ACORPUSER>micromamba shell reinit --shell cmd.exe --root-prefix=%MAMBA_ROOT_PREFIX%
The following arguments were not expected: cmd.exe --shell
Run with --help for more information.

mamba info / micromamba info

C:\Users\ACORPUSER>echo %MAMBA_ROOT_PREFIX%
C:\Users\ACORPUSER/.conda/envs/mmbase
 
C:\Users\ACORPUSER>micromamba info
       libmamba version : 2.0.4
     micromamba version : 2.0.4
           curl version : libcurl/8.8.0-DEV Schannel zlib/1.3.1
     libarchive version : libarchive 3.7.2 zlib/1.3.1 liblzma/5.6.2 bz2lib/1.0.8 liblz4/1.9.4 libzstd/1.5.6
       envs directories : C:\Users\ACORPUSER\.conda\envs
          package cache : C:\Users\ACORPUSER\.conda\envs\mmbase\pkgs
                          C:\Users\ACORPUSER\.mamba\pkgs
                          C:\Users\ACORPUSER\AppData\Roaming\.mamba\pkgs
            environment : base
           env location : C:\Users\ACORPUSER\.conda\envs\mmbase
      user config files : C:\Users\ACORPUSER\.mambarc
populated config files : C:\Users\ACORPUSER\.mambarc
                          C:\Users\ACORPUSER\.condarc
       virtual packages : __win=10.0.22631=0
                          __archspec=1=x86_64
                          __cuda=12.2=0
               channels : https://corp-artifactory.corp.internal/artifactory/ext-conda-forge-proxy/noarch
                          https://corp-artifactory.corp.internal/artifactory/ext-conda-forge-proxy/win-64
       base environment : C:\Users\ACORPUSER\.conda\envs\mmbase
               platform : win-64

Logs

See above

environment.yml

N/A

~/.condarc

# this .condarc works: tested successfully with conda (from miniforge)

channel_alias: https://corp-artifactory.corp.internal/artifactory

channels:
- ext-conda-forge-proxy

env_dirs:
- c:\Users\ACORPUSER\.conda\envs

ssl_verify: c:\Users\ACORPUSER\bin\ca-bundle.crt

[atticusmatticus]

I'm having the same issue on Fedora Linux.

$ micromamba info

       libmamba version : 2.0.5
          mamba version : 2.0.5
           curl version : libcurl/8.11.1 OpenSSL/3.4.0 zlib/1.3.1 brotli/1.1.0 zstd/1.5.6 libidn2/2.3.7 libssh2/1.11.1 nghttp2/1.64.0 librtmp/2.3 OpenLDAP/2.6.9
     libarchive version : libarchive 3.7.7 zlib/1.3.1 liblzma/5.6.3 bz2lib/1.0.8 liblz4/1.10.0 libzstd/1.5.6
       envs directories : /home/USER/micromamba/envs
          package cache : /home/USER/micromamba/pkgs
                          /home/USER/.mamba/pkgs
            environment : base (active)
           env location : /home/USER/micromamba
      user config files : /home/USER/.mambarc
 populated config files : /home/USER/.mambarc
       virtual packages : __unix=0=0
                          __linux=6.12.4=0
                          __glibc=2.39=0
                          __archspec=1=x86_64_v3
               channels : https://conda.anaconda.org/conda-forge/linux-64
                          https://conda.anaconda.org/conda-forge/noarch
                          https://conda.anaconda.org/nodefaults/linux-64
                          https://conda.anaconda.org/nodefaults/noarch
       base environment : /home/USER/micromamba
               platform : linux-64

[untitled9074]

After upgrading mamba from 1.5.something to 2.0.5. yesterday I cannot activate any of my environments as well:

$ mamba activate base

'mamba' is running as a subprocess and can't modify the parent shell.
Thus you must initialize your shell before using activate and deactivate.

To initialize the current fish shell, run:
    $ eval "$(mamba shell hook --shell fish)"
and then activate or deactivate with:
    $ mamba activate
To automatically initialize all future (fish) shells, run:
    $ mamba shell init --shell fish --root-prefix=~/.local/share/mamba
If your shell was already initialized, reinitialize your shell with:
    $ mamba shell reinit --shell fish
Otherwise, this may be an issue. In the meantime you can run commands. See:
    $ mamba run --help

Supported shells are {bash, zsh, csh, posix, xonsh, cmd.exe, powershell, fish, nu}.
critical libmamba Shell not initialized

mamba info

       libmamba version : 2.0.5
          mamba version : 2.0.5
           curl version : libcurl/8.11.1 OpenSSL/3.4.0 zlib/1.3.1 zstd/1.5.6 libssh2/1.11.1 nghttp2/1.64.0
     libarchive version : libarchive 3.7.7 zlib/1.3.1 liblzma/5.6.3 bz2lib/1.0.8 liblz4/1.10.0 libzstd/1.5.6
       envs directories : /home/user1/miniforge3/envs
          package cache : /home/user1/miniforge3/pkgs
                          /home/user1/.mamba/pkgs
            environment : base
           env location : /home/user1/miniforge3
      user config files : /home/user1/.mambarc
 populated config files : /home/user1/.condarc
                          /home/user1/miniforge3/.condarc
       virtual packages : __unix=0=0
                          __linux=6.8.0=0
                          __glibc=2.39=0
                          __archspec=1=x86_64_v3
                          __cuda=12.4=0
               channels : https://conda.anaconda.org/conda-forge/linux-64
                          https://conda.anaconda.org/conda-forge/noarch
       base environment : /home/user1/miniforge3
               platform : linux-64

Ubuntu 24.04
Linux hws 6.8.0-51-generic #52-Ubuntu SMP PREEMPT_DYNAMIC Thu Dec 5 13:09:44 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

[dxyzx0]

Save here on arch linux.

$ mamba activate /home/user/mambaforge/envs/msjr

'mamba' is running as a subprocess and can't modify the parent shell.
Thus you must initialize your shell before using activate and deactivate.

To initialize the current fish shell, run:
    $ eval "$(mamba shell hook --shell fish)"
and then activate or deactivate with:
    $ mamba activate
To automatically initialize all future (fish) shells, run:
    $ mamba shell init --shell fish --root-prefix=~/.local/share/mamba
If your shell was already initialized, reinitialize your shell with:
    $ mamba shell reinit --shell fish
Otherwise, this may be an issue. In the meantime you can run commands. See:
    $ mamba run --help

Supported shells are {bash, zsh, csh, posix, xonsh, cmd.exe, powershell, fish, nu}.
critical libmamba Shell not initialized

$ mamba info

       libmamba version : 2.0.5
          mamba version : 2.0.5
           curl version : libcurl/8.11.1 OpenSSL/3.4.0 zlib/1.3.1 zstd/1.5.6 libssh2/1.11.1 nghttp2/1.64.0
     libarchive version : libarchive 3.7.7 zlib/1.3.1 liblzma/5.6.3 bz2lib/1.0.8 liblz4/1.10.0 libzstd/1.5.6
       envs directories : /home/user/.local/share/mamba/envs
          package cache : /home/user/.local/share/mamba/pkgs
                          /home/user/.mamba/pkgs
            environment : base
           env location : /home/user/.local/share/mamba
      user config files : /home/user/.mambarc
 populated config files : /home/user/.condarc
       virtual packages : __unix=0=0
                          __linux=6.12.8=0
                          __glibc=2.40=0
                          __archspec=1=x86_64_v3
                          __cuda=12.7=0
               channels : https://conda.anaconda.org/conda-forge/linux-64
                          https://conda.anaconda.org/conda-forge/noarch
       base environment : /home/user/.local/share/mamba
               platform : linux-64

Archlinux:

Linux user-pc 6.12.8-arch1-1 #1 SMP PREEMPT_DYNAMIC Thu, 02 Jan 2025 22:52:26 +0000 x86_64 GNU/Linux

[Klaim]

@dxyzx0 Note that mamba activate requires a prefix name, not a path to it.

Linux users: did you all mamba shell init ... first? It's not clear to me if you are seeing the exact same issue as the @oscar6echo which has the problem on windows where shell init is a bit different.

[dxyzx0]

@dxyzx0 Note that mamba activate requires a prefix name, not a path to it.

Linux users: did you all mamba shell init ... first? It's not clear to me if you are seeing the exact same issue as the @oscar6echo which has the problem on windows where shell init is a bit different.

Sorry I have tried envName and prefx + envName. Both not work.

Same issue as the one above mine on ubuntu after upgrade to 2.0.5. And I have tried all the mamba shell init ... ways which are not helpful.

[Klaim]

And I have tried all the mamba shell init ... ways which are not helpful.

Do you mean that shell-init fails, or does it succeeds but doesnt help with activate?

[dxyzx0]

And I have tried all the mamba shell init ... ways which are not helpful.

Do you mean that shell-init fails, or does it succeeds but doesnt help with activate?

Sorry for the confusion. The shell-init succeeds ( no error output), but the activate still fails.

[untitled9074]

Linux users: did you all mamba shell init ... first? It's not clear to me if you are seeing the exact same issue as the @oscar6echo which has the problem on windows where shell init is a bit different.

@Klaim in my case a perfectly functional mamba installation stopped working after the upgrade. Rolling back mamba upgrade and pinning 1.5.* version solved the issue for me. iirc I did try to re-init.