Motivation and vision#
Motivation#
The conda activate and conda deactivate subcommands were inspired by the virtualenv workflow, which implied source-ing a shell script shipped in the virtual environment directory. Initially implemented as source activate and source deactivate, these subcommands were promoted to the conda command namespace in version 4.4.0.
The 4.4.0 activation workflow is still used in conda (as of 25.1) and it goes a long way to provide the possibility of modifying the shell session in place. conda activate will modify PATH, inject a few environment variables and run some activation scripts. Then, conda deactivate needs to undo this. That’s a lot of work (and code to maintain), specially considering we can accomplish the same thing in an easier way by starting a new shell with the needed modifications and then discarding the process once done. No cleanup necessary!
However, that’s not all. In order to provide in-process shell state updates, the conda Python entry point needs to be wrapped by a conda shell function that intercepts the subcommands and dispatches to either shell subcommands or regular Python subcommands. Installing that shell function cannot be handled by regular Python packaging operations, so a block of code is injected in your shell profile (or platform equivalent). This is what conda calls “initialize your shell”, as provided in conda init.
The conda shell function wrapper and the initialization logic have a non-negligible maintenance cost, add testing burden, obfuscate the application model, and, more importantly, complicate the end-user installation in a very invasive way: the shell startup profile needs a block of code to define the conda shell function and auto-activation mechanisms. This has a non-negligible cost every time you start a login shell and leaves residual information on uninstalls.
Vision#
This project is inspired by the workflows implemented in poetry shell and pixi shell. These workflows prove that no shell initialization logic is needed for effective virtual environment management.
The idea is to start new shell processes and then run the activation logic inside them. Once done, the user exits the process and returns to the parent session. This requires no shell function wrapper, which renders all the logic in conda init unnecessary; we only need $CONDA_ROOT/condabin in PATH so we can cleanly find the conda entry point.
For now, this idea is distributed as an optional plugin. If proven successful and it’s well received by the community, we would propose adding it as a default conda plugin and suggest deprecating the old workflow (conda init, activate and deactivate).