Nick Coghlan <ncoghlan <at> gmail.com> writes:
1. However we end up solving the bootstrapping problem, I'm *definitely* a fan of us updating pyvenv in 3.4 to ensure that pip is available by default in new virtual environments created with that tool.
Will that need green-lighting on python-dev? As events have shown, that script has needed updating between Python releases. OTOH, I'm not sure anyone could have predicted at 3.3 release time that setuptools and Distribute would kiss and make up :-) We should probably ensure that the pip and setuptools URLs used in that script (pyvenvex.py, to be renamed to pyvenv.py) are formally agreed with the relevant maintainers. Or, since those URLs just fetch the latest releases, perhaps some different URLs should be used which refer to more stable releases (for some definition of "more stable") - perhaps those should be python.org URLs, rather than BitBucket and GitHub as they are at present. That way, changing the resources which those URLs reference would have to be an active decision by someone, rather than just following the latest developments on setuptools and pip. There are pluses and minuses either way, of course.
2. While I was originally a fan of the "implicit bootstrapping on demand" design, I no longer like that notion. While Richard's bootstrap script is a very nice piece of work, the edge cases and "neat tricks" have built up to the point where they trip my "if the implementation is hard to explain, it's a bad idea" filter. Accordingly, I no longer think the implicit bootstrapping is a viable option.
But if your reservation stems from one specific implementation of the idea, then might not an alternative implementation fit the bill? Consider: the pyvenvex.script merely runs bootstrapping scripts from setuptools and pip in the venv - there's no magic. I couldn't see Richard's script referenced in the PEP, which just referred to the PIP issue tracker which had no obvious link to any commit or script. So I don't know what the edge cases and neat tricks are that you're referring to. I adapted the pyvenvex.py script into a getpip.py script, available here: https://gist.github.com/vsajip/5990837 82 lines all told - what cases does it not cover? It installs setuptools and pip into the system site-packages for the invoking Python, if not already present. It can, of course, be refined to e.g. install even if the packages are already present, which is tantamount to upgrading. I smoke-tested the script on vanilla Python 3.3 installations on Windows and OS X. On OS X, the pip script was written to the appropriate Frameworks folder, but not to /usr/local/bin - I assume it would be simple enough to arrange that? On Windows, the pip script (including Windows native launcher) were written to c:\Python33\Scripts.
The bundling idea will obviously need to be discussed with the installer builders, and on python-dev in general
If python-dev agrees to the updated pyvenv.py script, then this type of addition should be uncontentious, as it basically does the same thing. It seems a whole lot less work than bundling, to me. Regards, Vinay Sajip