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
GitHub fields:
assignee='https://github.com/asvetlov'closed_at=<Date2012-10-04.18:50:27.570>created_at=<Date2012-07-22.00:04:37.878>labels= ['library']
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.
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.
Activity
asvetlov commented on Jul 22, 2012
I have added required shell files
asvetlov commented on Jul 22, 2012
No idea if Doc/using/venv-create.inc should be updated to reflect support of new shells.
virtualenv does nothing in own documentation btw.
vsajip commented on Jul 23, 2012
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.
asvetlov commented on Jul 23, 2012
I agree with you about exclusion from 3.3.
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.
vsajip commented on Jul 23, 2012
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.
python-dev commented on Oct 4, 2012
New changeset c519b490f4e4 by Andrew Svetlov in branch 'default':
Issue bpo-15417: Add support for csh and fish in venv activation scripts.
http://hg.python.org/cpython/rev/c519b490f4e4