You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
title='Add support for csh and fish in venv activation scripts'updated_at=<Date2012-10-04.18:50:27.569>user='https://github.com/asvetlov'
I have no objection in principle to supporting additional shells, but do have the following comments/questions:
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.
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.
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.
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.