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

[Nick Coghlan]

In addition to the long thread based on Richard's latest set of updates,
I've also received a few off-list comments on the current state of the
proposal. So, I figured I'd start a new thread summarising my current point
of view and see where we want to go from there.

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. I also have an idea for
a related import system feature that I'll be sending to import-sig this
afternoon (it's a variant on *.pth and *.egg-link files that should be able
to address a variety of existing problems, including the one of
*selectively* making system and user packages available in a virtual
environment in a cross-platform way without needing to copy them)

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.

3. That means there are two main options available to us that I still
consider viable alternatives (the installer bundling idea was suggested in
one of the off list comments I mentioned):

* an explicit bootstrapping script
* bundling a *full* copy of pip with the Python installers for Windows and
Mac OS X, but installing it to site-packages rather than to the standard
library directory. That way pip can be used to upgrade itself as normal,
rather than making it part of the standard library per se. This is then
closer to the "bundled application" model adopted for IDLE in PEP 434 (we
could, in fact, move to distributing idle the same way).

I'm currently leaning towards offering both, as we're going to need a tool
for bootstrapping source builds, but the simplest way to bootstrap pip for
Windows and Mac OS X users is to just *bundle a copy with the binary
installers*. So long as the bundled copy looks *exactly* the way it would
if installed later (so it can update itself), then we avoid the problem of
coupling the pip update cycles to the standard library feature release
cycle. The bundled version can be updated to the latest available versions
when we do a Python maintenance release.

For Linux, if you're using the system Python on a Debian or Fedora
derivative, then "sudo apt-get python-pip" and "sudo yum install
python-pip" are both straightforward, and if you're using something else,
then it's unlikely getting pip bootstrapped using the bootstrap script is a
task that will bother you :)

The "python -m getpip" command is still something we will want to provide,
as it is useful to people that build their own copy of Python from source.

The bundling idea will obviously need to be discussed with the installer
builders, and on python-dev in general, but that was always going to be the
case for this PEP anyway (since it *does* touch CPython directly, rather
than just being related to the packaging ecosystem). It achieves the aim of
allowing people to assume some version of pip will be present on Python
3.4+ installations (or readily available in the case of Linux), while
avoiding the problem of coupling pip updates to major Python version
updates.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130713/2122bb9c/attachment-0001.html>