Call pre,post_command with more arguments (args, CLI invocation)

[jaimergp]

Checklist

• I added a descriptive title
• I searched open requests and couldn't find a duplicate

What is the idea?

Plugins implementing the pre,post_command hooks should have access to the full invocation, not just the subcommand name. This allows for more flexible introspection of what to do under certain conditions.

Why is this needed?

Current implementation only passes the command name.

What should happen?

def do_call(args: argparse.Namespace, parser: ArgumentParser):
    """
    Serves as the primary entry point for commands referred to in this file and for
    all registered plugin subcommands.
    """
    # let's see if during the parsing phase it was discovered that the
    # called command was in fact a plugin subcommand
    if plugin_subcommand := getattr(args, "_plugin_subcommand", None):
        # pass on the rest of the plugin specific args or fall back to
        # the whole discovered arguments
        context.plugin_manager.invoke_pre_commands(plugin_subcommand.name)
        result = plugin_subcommand.action(getattr(args, "_args", args))
        context.plugin_manager.invoke_post_commands(plugin_subcommand.name)
        ...

Should become

def do_call(args: argparse.Namespace, parser: ArgumentParser):
    """
    Serves as the primary entry point for commands referred to in this file and for
    all registered plugin subcommands.
    """
    # let's see if during the parsing phase it was discovered that the
    # called command was in fact a plugin subcommand
    if plugin_subcommand := getattr(args, "_plugin_subcommand", None):
        # pass on the rest of the plugin specific args or fall back to
        # the whole discovered arguments
        context.plugin_manager.invoke_pre_commands(plugin_subcommand.name, args=args)
        result = plugin_subcommand.action(getattr(args, "_args", args))
        context.plugin_manager.invoke_post_commands(plugin_subcommand.name, args=args)
        ...

I guess we'll have to add a new plugin hook type PostCommandWithArgs or something similar to not break any API.

Additional Context

Finding this limitation in the development of conda-checkpoints, where I can't find the original command to annotate the checkpoint with. We can use sys.argv but that might be blank if called from the conda_cli() wrapper or other Python invocations.

[travishathaway]

Is there a reason we can't just use?

from conda.base.context import context

context.raw_data["cmd_line"]

I know it's not the prettiest data to work with 😅. Here's what it looks like for conda info --base:

{
  'base': {
    'source': 'cmd_line', 'key': 'base', '_raw_value': True
  },
  'cmd': {
    'source': 'cmd_line', 'key': 'cmd', '_raw_value': 'info'
  },
  'envs': {
    'source': 'cmd_line', 'key': 'envs', '_raw_value': False
  },
  'func': {
    'source': 'cmd_line', 'key': 'func', '_raw_value': 'conda.cli.main_info.execute'
  },
  'license': {
    'source': 'cmd_line', 'key': 'license', '_raw_value': False
  },
  'system': {
    'source': 'cmd_line', 'key': 'system', '_raw_value': False
  },
  'unsafe_channels': {
    'source': 'cmd_line', 'key': 'unsafe_channels', '_raw_value': False
  }
}

That should give you everything you need though, right?

raw_data technically isn't a protected property of context either. Although, I'm sure it's probably not best practice to be reading directly from this object (e.g. if we ever change the underlying configuration system implementation). But, I think I would prefer that over making a new PostCommandWithArgs class.

Maybe instead, we should make something like "cli_args" available on the context object? Going forward this would appear the same regardless of the underlying configuration system implementation.

Just some food for though 🍎.

[jaimergp]

Huh, I wasn't aware of that attribute. That could work. Although I do agree is probably a bad idea :P context.cli_args containing a dict dump of the argparse namespace doesn't sound like too bad of an idea, but we would need to see how this plays out with subcommand plugins modifying the parser as part of the initialization and so on... It should be ok for pre and post commands, though.

[jaimergp]

we should make something like "cli_args" available on the context object?

Apparently we have it at context._argparse_args... 😬

[jaimergp]

For those reading, I'm using context.raw_data["cmd_line"] as a way of querying the arguments. To note:

• context.raw_data["cmd_line"] is a dictionary of str, RawArgParseArgument.
• RawArgParseArgument is a context internal detail that happens to str as JSON. But it's actually an object.
• bool(RawArgParseArgument(...)) is always true. To access the value via the public API, you must use RawArgParseArgument(...).value(None). There's a positional argument there that doesn't seem to be used in most cases, but you need to pass something.