[Distutils] PEP 453 Round 2 - Explicit bootstrapping of pip in Python installations

[Nick Coghlan]

On 16 Sep 2013 19:55, "Oscar Benjamin" <oscar.j.benjamin at gmail.com> wrote:
>
> On 15 September 2013 16:33, Donald Stufft <donald at stufft.io> wrote:
> > So there've been a number of updates to PEP453, so i'm posting it here
again for more discussion:
> >
>
> > Explicit Bootstrapping
> > ======================
> >
> > An additional module called ``getpip`` will be added to the standard
library
> > whose purpose is to install pip and any of its dependencies into the
> > appropriate location (most commonly site-packages). It will expose a
single
> > callable named ``bootstrap()`` as well as offer direct execution via
> > ``python -m getpip``. Options for installing it such as index server,
> > installation location (``--user``, ``--root``, etc) will also be
available
> > to enable different installation schemes.
> >
> > It is believed that users will want the most recent versions available
to be
> > installed so that they can take advantage of the new advances in
packaging.
> > Since any particular version of Python has a much longer staying power
than
> > a version of pip in order to satisfy a user's desire to have the most
recent
> > version the bootstrap will contact PyPI, find the latest version,
download it,
> > and then install it. This process is security sensitive, difficult to
get
> > right, and evolves along with the rest of packaging.
> >
> > Instead of attempting to maintain a "mini pip" for the sole purpose of
> > installing pip the ``getpip`` module will, as an implementation detail,
> > include a private copy of pip and its dependencies which will be used to
> > discover and install pip from PyPI. It is important to stress that this
> > private copy of pip is *only* an implementation detail and it should
*not*
> > be relied on or assumed to exist.
> >
> > Not all users will have network access to PyPI whenever they run the
> > bootstrap. In order to ensure that these users will still be able to
> > bootstrap pip the bootstrap will fallback to simply installing the
included
> > copy of pip. The pip ``--no-download`` command line option will be
supported
> > to force installation of the bundled version, without even attempting to
> > contact PyPI.
> >
> > This presents a balance between giving users the latest version of pip,
> > saving them from needing to immediately upgrade pip after bootstrapping
it,
> > and allowing the bootstrap to work offline in situations where users
might
> > already have packages downloaded that they wish to install.
>
> I still don't understand why this is preferable to just shipping a
> recent stable pip/setuptools and providing instructions to update
> post-install. That would surely be a lot simpler not just to implement
> but for others to understand.
>
> If I'm happy to use the bundled version of pip then why do I need to
> do anything to make it usable after having already run the installer?
> If I want the new version then why is 'py -m getpip' better than 'py
> -m pip install -U pip'?

You don't, the installer bootstraps it for you. Running it explicitly
should only be needed when building from source, or bootstrapping a
previously pip-free virtual environment.

The complicated bootstrapping dance is both to make pip easy to leave out
if people really don't want it and to avoid the CPython platform installers
and pip getting into a fight about who is responsible for the files.

> > Recommendations for Downstream Distributors
> > ===========================================
> >
> > A common source of Python installations are through downstream
distributors
> > such as the various Linux Distributions [#ubuntu]_ [#debian]_
[#fedora]_, OSX
> > package managers [#homebrew]_, or python specific tools [#conda]_. In
order to
> > provide a consistent, user friendly experience to all users of Python
> > regardless of how they attained Python this PEP recommends and asks that
> > downstream distributors:
> >
> > * Ensure that whenever Python is installed pip is also installed.
> >
> >   * This may take the form of separate packages with dependencies on
each
> >     other so that installing the Python package installs the pip package
> >     and installing the pip package installs the Python package.
> >
> > * Do not remove the bundled copy of pip.
>
> Are distros really going to be okay with this idea? Many of them have
> CPython in their base install so you're basically asking that they
> always ship a parallel package management system that is outside of
> their control.

Fedora is fine with it (we discussed it at Flock last month), while Ubuntu
(and Debian?) already splits out a "python-core" package for inclusion on
the installation media, so should be fine with having the full python have
a circular dependency with pip.

Other distros will be free to make their own decisions, but I believe they
all already tolerate this bundling approach inside virtualenv.

Windows and Mac OS X users are intended as the main beneficiaries though -
bootstrapping pip with yum, apt, etc is much easier than bootstrapping it
on either of those platforms.

> Personally I think that it's unfortunate that distro package managers
> don't have a --user option like pip does but I've always assumed that
> they had some good reason for not wanting any old user to be able to
> easily install things without admin/root privileges. This would break
> that arrangement since any user would be able to use 'pip install
> --user' to install anything from PyPI. I imagine that lots of
> deployment sites would want to disable this even if the distro has it
> enabled by default.

Yep, but there are plenty of options available to do that, and the better
ones work even if users download and install pip directly.

Our target audience here is the beginning enthusiast (regardless of OS).
Sophisticated users (including admins that want to lock their system down)
can still do so if they really want to.

Cheers,
Nick.

>
>
> Oscar
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130916/e5139c42/attachment-0001.html>