[Distutils] Current status of PEP 439 (pip boostrapping)

[Vinay Sajip]

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