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

[Paul Moore]

On 15 September 2013 16:33, Donald Stufft <donald at stufft.io> wrote:
[...]
> ``pip`` currently depends on ``setuptools`` to handle metadata generation
> during the build process, along with some other features. While work is
> ongoing to reduce or eliminate this dependency, it is not clear if that
> work will be complete for pip 1.5 (which is the version likely to be
> bundled with Python 3.4.0).

Might be better worded as "(which is the version likely to be current
when Python 3.4.0 is released)",

> This PEP proposes that, if pip still requires it, ``setuptools`` will be
> bundled along with pip itself, and thus installed when running
> ``python -m getpip``.

Do you mean "thus installed"? Surely the current version from PyPI
will be installed except in --no-download cases?

Actually, I'd be inclined to avoid the use of the word "bundled".
getpip has an "internal copy" of pip, which users aren't supposed to
care about except for the fact that it's the "static version included
for offline installation", and there's also the "current version on
PyPI" which is what is normally installed. I don't think that any of
the 3 quoted terms really corresponds to "bundled" in the sense that
people will expect it to mean.

> Updating the bundled pip
> ------------------------
[..]
> This means that maintenance releases of the CPython installers will include
> an updated version of the ``getpip`` bootstrap module.

Is this *solely* the copy of pip that will be updated, or if there are
logic changes in getpip itself (I can't immediately think of any that
might be added) will they be included as well?

> While the Windows installer was updated in Python 3.3 to make ``python``
> available on the PATH,

Correction: it was updated to *optionally* make Python available, and
the option is off by default.

> no such change was made to include the scripts
> directory. This PEP proposes that this be changed to also add the scripts
> directory.
>
> Without this change, the most reliable way to invoke pip on Windows (without
> tinkering with paths) is actually be ``py -m pip`` (or ``py -3 -m pip``
> if both Python 2 and 3 are installed) rather than simply calling ``pip``.
>
> Adding the scripts directory to the system PATH would mean that ``pip``
> works reliably in the "only one Python installation" case, with
> ``py -m pip`` needed only for the parallel installation case.

Technically, for the 'the user only selected the "put Python on PATH"
option for one installation" case.... And if the user selected it more
than once, they are already in the land of confusing which-comes-first
PATH ordering fun, so working out which pip gets run won't be much
extra pain :-)

I think it's also still an open question as to whether getpip should
be run in --user mode by default (or as an option) as part of the
installation process. There are issues around PATH with doing so, as
well as possible confusion because pip does not default to --user. I
suspect that the probably answer here should be "--user installs are
too immature at the moment to have as the default, but we should look
at this again later".

But these minor points aside, I'm +1 on this.

Paul