Antoine Pitrou <solipsis <at> pitrou.net> writes:
Why would that be a problem? Do you plan to install several versions of Python in a single VE?
No, but some packages might install headers in /include and others in /include/pythonX.Y. I wasn't sure whether this would cause a problem with files not being found during build, though I realise this can be worked around with specific -I flags to the compiler.
At present, we only create a /include in the venv, but not /include/pythonX.Y.
We already have Unix shell scripts and BAT files in the source tree. Is it really complicated to maintain these additional shell scripts? Is there a lot of code in them?
No, they're pretty small: wc -l gives
76 posix/activate (Bash script, contains deactivate() function) 31 nt/activate.bat 17 nt/deactivate.bat
The question is whether we should stop at that, or whether there should be support for tcsh, fish etc. such as virtualenv provides.
IMO, if we provide the above as a bare minimum + an easy way for third-party tools to install replacements/additions, then we probably don't need to worry too much about an additional support burden in the stdlib - third parties can take up the responsibility for supporting additional shells or helper scripts.