Porting xonsh hook fixes from conda to mamba

[battaglia01]

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

Nothing here

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

These are two issues with the xonsh shell hook, both of which were resolved in conda several years ago and need to be ported to mamba. There are also two other small issues in the same shell hook, also pertaining to xonsh support though not in conda, and since they are all related, I've just put them all here in the same issue. These are all one-line or "a-few-line" patches.

1 micromamba --help doesn't work

First, as in Conda #12324, we get this issue:

$ micromamba --help
usage: xonsh command
xonsh: error: the following arguments are required: command

The solution, as in the original issue, is to update the outputted _parse_args() function here:

mamba/libmamba/data/mamba.xsh

Lines 20 to 31 in 4823aee

	def _parse_args(args=None):
	from argparse import ArgumentParser
	p = ArgumentParser(add_help=False)
	p.add_argument('command')
	ns, _ = p.parse_known_args(args)
	if ns.command == 'activate':
	p.add_argument('env_name_or_prefix', default='base')
	elif ns.command in _REACTIVATE_COMMANDS:
	p.add_argument('-n', '--name')
	p.add_argument('-p', '--prefix')
	parsed_args, _ = p.parse_known_args(args)
	return parsed_args

This should be

def _parse_args(args=None):
    from argparse import ArgumentParser
    p = ArgumentParser(add_help=False)
    p.add_argument('command', nargs='?') # added nargs
    p.add_argument('-h', '--help', dest='help', action='store_true', default=False) # added this
    p.add_argument('-v', '--version', dest='version', action='store_true', default=False) # added this
    ns, _ = p.parse_known_args(args)
    if ns.command == 'activate':
        p.add_argument('env_name_or_prefix', default='base')
    elif ns.command in _REACTIVATE_COMMANDS:
        p.add_argument('-n', '--name')
        p.add_argument('-p', '--prefix')
    parsed_args, _ = p.parse_known_args(args)
    return parsed_args

2 Changing envs tries to del nonexistent env vars and crashes

The second issue, as in Conda #14543, is that when changing envs using micromamba activate __, it sometimes tries to unset environment variables that don't exist and crashes. This is because the "del" keyword doesn't work like "unset" in bash; if you try to "del" something that doesn't exist, it causes a traceback. For instance, every time I switch from my "core" environment to "base", I get

xonsh: For full traceback set: $XONSH_SHOW_TRACEBACK = True
xonsh: subprocess mode: command not found: '$MPLCURSORS'
Command '$mplcursors' not found in any conda package.

because $MPLCURSORS is only defined in core. This actually crashes and doesn't change envs.

I think this is here:

mamba/libmamba/src/core/activation.cpp

Line 1126 in 4823aee

out << "del $" << uvar << "\n";

And again, the solution in the conda issue above should still work. Instead of

        for (const std::string& uvar : env_transform.unset_vars)
        {
            out << "del $" << uvar << "\n";
        }

replace it with something like

        for (const std::string& uvar : env_transform.unset_vars)
        {
            out << "try:\n  del $" << uvar << "\nexcept KeyError:\n  pass\n";
        }

3 - micromamba activate ___ forces -p

This is another one-line fix, though it wasn't in the original conda issues above. Right now, every single time you do micromamba activate ____, you get this ridiculous nag:

$ micromamba activate core
warning  libmamba 'core' does not contain any filesystem separator.
    It will be handled as env name, resulting to the following
    'target_prefix': '/Users/mike/Library/miniconda3/envs/core'
    If 'target_prefix' is expressed as a relative directory to
    the current working directory, use './some_prefix'

This is because the shell hook, somewhat inexplicably, forces -p:

mamba/libmamba/data/mamba.xsh

Lines 44 to 49 in 4823aee

	def _mamba_activate_handler(env_name_or_prefix=None):
	if env_name_or_prefix == 'base' or not env_name_or_prefix:
	env_name_or_prefix = $MAMBA_ROOT_PREFIX
	__xonsh__.execer.exec($($MAMBA_EXE shell activate -s xonsh -p @(env_name_or_prefix)),
	glbs=__xonsh__.ctx,
	filename="$($MAMBA_EXE shell activate -s xonsh -p " + env_name_or_prefix + ")")

Getting rid of the -p's solves that:

def _mamba_activate_handler(env_name_or_prefix=None):
    if env_name_or_prefix == 'base' or not env_name_or_prefix:
        env_name_or_prefix = $MAMBA_ROOT_PREFIX
    __xonsh__.execer.exec($(/Users/mike/Library/miniconda3/condabin/mamba shell activate -s xonsh @(env_name_or_prefix)),
                          glbs=__xonsh__.ctx,
                          filename="$(/Users/mike/Library/miniconda3/condabin/mamba shell activate -s xonsh " + env_name_or_prefix + ")")

4 - Adding mamba alias

Lastly, for whatever reason, the shell hook currently sets only the alias micromamba. Setting mamba would probably be much better. So just add this

aliases['micromamba'] = _micromamba_main
aliases['mamba'] = _micromamba_main # new

This also solves the issue of mamba deactivate not working:

(core) $ which mamba
/Users/mike/Library/miniconda3/condabin/mamba
(core) $ mamba deactivate
The following argument was not expected: deactivate
Run with --help for more information.
(core) $ aliases['mamba'] = aliases['micromamba']
(core) $ which mamba
<function _micromamba_main at 0x1163a54e0>
(core) $ mamba deactivate
$

None of these issues seem to happen in anything but the xonsh shell hook.

mamba info / micromamba info

libmamba version : 2.5.0
          mamba version : 2.5.0
           curl version : libcurl/8.19.0 OpenSSL/3.6.2 zlib/1.3.2 zstd/1.5.7 libssh2/1.11.1 nghttp2/1.68.1 mit-krb5/1.22.2
     libarchive version : libarchive 3.8.6 zlib/1.3.2 liblzma/5.8.2 bz2lib/1.0.8 liblz4/1.10.0 libzstd/1.5.7 liblzo2/2.10 CommonCrypto/system libb2/bundled
       envs directories : /Users/mike/Library/miniconda3/envs
          package cache : /Users/mike/Library/miniconda3/pkgs
                          /Users/mike/.mamba/pkgs
            environment : core (active)
           env location : /Users/mike/Library/miniconda3/envs/core
      user config files : /Users/mike/.mambarc
 populated config files : /Users/mike/.mambarc
                          /Users/mike/.condarc
       virtual packages : __unix=0=0
                          __osx=14.5=0
                          __archspec=1=arm64
               channels : https://conda.anaconda.org/conda-forge/noarch
                          https://conda.anaconda.org/conda-forge/osx-arm64
                          https://repo.anaconda.com/pkgs/main/noarch
                          https://repo.anaconda.com/pkgs/main/osx-arm64
                          https://repo.anaconda.com/pkgs/r/noarch
                          https://repo.anaconda.com/pkgs/r/osx-arm64
       base environment : /Users/mike/Library/miniconda3
               platform : osx-arm64

Logs

environment.yml

~/.condarc

$ cat ~/.condarc
channels:
  - conda-forge
  - defaults

pip_interop_enabled: true
solver: libmamba

auto_activate_base: false