Conda Shell Plugin Hook and Plugin Architecture

[kalawac]

This CEP proposes a potential template for a plugin hook and associated plugin architecture that can carry out the process of activating and deactivating conda environments. Extracting this logic to plugins will enable the conda community to support activation and deactivation processes for a wider variety of shells. In addition, the use of plugins for activation will reduce the present burden on conda's maintainers in managing requests for expansion of conda's environment activation and deactivation logic to additional shells.

Please check what is currently on the CEP and use this pull request as a forum to discuss changes or points of opposition to the proposal.

[jaimergp]

Thanks for such a nice and thorough writeup! I learnt a lot while reading this. I am generally in support of the idea, but I have some questions regarding its implementation and deployment plans:

• Deprecation plans. If I understood correctly, this method will add a subcommand conda shell that will allow users to activate environments in a subshell. This does not replace (for now) conda (de)activate. One of the points of this CEP is to reduce maintenance burden, but so far it will only add one more layer to the codebase that needs to be tested. What are the plans to replace all the previous shell logic layers (there are a few generations!) with this one?
• In-process use cases. Assuming at some point this will be the only shell layer in active use, how is this going to achieve feature parity with the current one? You have mentioned problems with $PS1 and non-exported env vars. I didn't see anything about the valid use case of requiring in-process activation for e.g. scripts. We would need at least one way to write shell code to terminal so it can be eval'd.
• Pluggy overhead. This new plugin system forces the shell logic to "wait" for pluggy to be ready, which might mean waiting for all plugins to be ready before we can run activation. This might be significantly slower in installations with a lot of plugins or at least a couple heavy ones. Is there a chance we can skip that runtime burden for the shell hook? The current design is a bit clunky but in part it was designed like that to avoid going through unnecessary logic layers and imports. I'd be interested in tentative benchmarks.
• How does this compare to conda-workon? I don't think it's maintained but I think it should be in the reference list, as part of the prior art.
• I get how conda shell activate will take you to a sub-shell because the Python process will be replaced via os.execve. However, how will conda shell deactivate force an exit? Into one more shell? Wouldn't every new conda shell leave the user in a new sub-shell? At some point the user must issue a Ctrl+D, right?

Thank you!

[jaimergp]

Can we link to some of these issues ("historically received requests") for future reference? e.g.:

• Add conda init nushell conda#12406
• Add conda init csh conda#11116

[jaimergp]

Why PluginActivator instead of ActivatorPlugin?