It's maybe spicy to be changing this deprecation warning here? Not sure how conda's process for this is.

Oh, hmm, I'm not sure. @kenodegard did we have a case like this before? Could we keep a get_environment_specifiers stub around as an alias until this deprecation cycle is done?

Hm, do we need a new section for this? If it's experimental, we should maybe put it under "undocumented" for now?

I don't think this config field really fits in any of the other categories. Open to suggestions.

I don't think this should go in the undocumented section. But maybe could add an "experimental" section?

Oh, I'm in favor of an experimental section!

Me too, let's move it to experimental.

Can we depend on context bis at CLI initialization? My understanding is that the context needs the parsed CLI args to finish initialization, so I'm not sure we have discovered anything about plugins yet here 🤔 Would we need to validate later?

Erm, ya this is not great, I'd say. This happens other places in the code, for example with the --solver cli argument https://github.com/conda/conda/blob/main/conda/cli/helpers.py#L423.

My understanding is that the context needs the parsed CLI args to finish initialization,

yes, that'll be for slurping up all the config from all the different places it comes from. I don't think this is changing anything for plugin loading though. Like, all the plugins get discovered when the plugin manager gets initialized with plugin.manager::get_plugin_manager.

So, I think setting choices is an ok thing to do here. It is weird that configuration and other things that are expected to be globally accessible (like the plugin manager) and shoved into the context object.

That's a fair point, I've used something like this before, should maybe used for the solver option as well

import argparse

class LazyChoicesAction(argparse.Action):
    def __init__(self, option_strings, dest, choices_func, **kwargs):
        self.choices_func = choices_func
        super().__init__(option_strings, dest, **kwargs)
    
    def __call__(self, parser, namespace, values, option_string=None):
        valid_choices = self.choices_func()
        if values not in valid_choices:
            raise argparse.ArgumentTypeError(
                f"invalid choice: {values!r} (choose from {valid_choices})"
            )
        setattr(namespace, self.dest, values)

Oh, I had missed we do that with the solver already. I think we can apply Jannis' suggestion and fix the solver bits in a separate PR to aid with traceability.

Oh, I'm in favor of an experimental section!

That's a fair point, I've used something like this before, should maybe used for the solver option as well

import argparse

class LazyChoicesAction(argparse.Action):
    def __init__(self, option_strings, dest, choices_func, **kwargs):
        self.choices_func = choices_func
        super().__init__(option_strings, dest, **kwargs)
    
    def __call__(self, parser, namespace, values, option_string=None):
        valid_choices = self.choices_func()
        if values not in valid_choices:
            raise argparse.ArgumentTypeError(
                f"invalid choice: {values!r} (choose from {valid_choices})"
            )
        setattr(namespace, self.dest, values)

I like this