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

[Brett Cannon]

On Sat, Jul 13, 2013 at 1:31 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> 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.
>

But is it going to make a difference? If we shift to using included copies
of pip in binary installers over a bootstrap I say leave out the bootstrap
as anyone building from source should know how to get pip installed on
their machine or venv.

The only reason I see it worth considering is if pyvenv starts
bootstrapping pip and we want to support the case of pip not being
installed. But if we are including it in the binary installer and are going
to assume it's available through OS distros, then there isn't a need to as
pip can then install pip for us into the venv and skip any initial pip
bootstrap. If pip isn't found we can simply either point to the docs in the
failure message or print out the one-liner it takes to install pip (and
obviously there can be a --no-pip flag to skip this for people who want to
install it manually like me who build from source).

IOW I think taking the worldview in Python 3.4 that pip will come installed
with Python unless you build from source negates the need for the bootstrap
script beyond just saying ``curl https://pypi.python.org/get-pip.py |
python`` if pip isn't found.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130713/f99c5e51/attachment-0001.html>