I have no objection in principle to supporting additional shells, but do have the following comments/questions: 1. Georg feels that this is a new feature he doesn't want to add to 3.3. IMO we have to respect his judgement as RM, no matter how trivial the change might seem. It's more about the discipline of the process than it is about any one specific change. 2. Where do we draw the line in terms of support for ("arbitrary") shells? Each activation script will potentially need maintenance into the future. It was originally envisaged that the stdlib code would add minimal support for activation scripts and that third-party tools would add support for additional shells and other value-adding features. The venv API design was intended to facilitate usage by third-party code.
1. I agree with you about exclusion from 3.3. 2. Hmm. Good question. For now virtualenv has support for cmd.exe, csh, fish, bash/zsh and PowerShell. I propose to add csh and fish to venv too. If later somebody will push request for adding yet another shell support we can consider it. Personally I doubt if we will see many requests for that. 3. Which standard way to append new activation script in third-party tool? I see th only way: inherit from `venv.EnvBuilder` and override `setup_scripts` method pointing to new directory with desired activators as `path` parameter for `self.install_scripts(...)`. Also that third-party tool have to reimplement functionality of `create` and `main` functions with setting up ArgumentParser. Doesn't look like trivial steps if you wish to just add single activation script.
> inherit from `venv.EnvBuilder` and override `setup_scripts` method > pointing to new directory with desired activators as `path` parameter > for `self.install_scripts(...)`. Yes, that's it. A third party tool would potentially do more than just custom scripts, and would presumably have its own command line parameters and handling code, reflecting the features it offers.
