[Distutils] PEP453 - Explicit bootstrapping of pip in Python installations

[Nick Coghlan]

On 31 Aug 2013 02:02, "Paul Moore" <p.f.moore at gmail.com> wrote:
>
>
> On 30 August 2013 14:44, Donald Stufft <donald at stufft.io> wrote:
>>
>> The Windows and OSX installers distributed by Python.org will
automatically
>> attempt to run ``python -m getpip`` by default however the ``make
install``
>> and ``make altinstall`` commands of the source distribution will not.
>
>
> Presumably the uninstaller components of these installers should
similarly uninstall pip before uninstalling Python. Would something like a
"python -m getpip uninstall" command be worthwhile to support this? (That's
probably a question for the authors of the installers to answer, as I don't
know if such a command would be needed - I suspect that the Windows MSI
installer just records what files it installs and uninstalls them, so it
may not be needed there).
>
> But otherwise +1 on this PEP.

Yeah, a command to uninstall pip and everything it installed would be
desirable. I wouldn't consider it a *blocker* for inclusion (since anyone
bootstrapping pip manually already has this problem), but it would be a
nice one to solve (and having it on getpip neatly avoids the issues with
pip uninstalling itself on Windows).

For the other questions people asked:

* yes, pyvenv should gain a "--without-pip" option

* the only change to the existing get-pip.py bootstrap script should be to
check for "getpip" and use it if available, and otherwise continue on with
the legacy bootstrap mechanism.

* I agree with Donald that getpip should be an ordinary standard library
Python module

* To allow releases to be recreated exactly from the source tarball, I
agree with Donald that we need to actually include the relevant wheel files
inside the CPython source tree. Retrieving them automatically at build time
would be nice, but that unfortunately creates ugly version reproducibility
issues, and also requires that the build process be patched before it can
run on a trusted build server with no network access.

* If we have to bundle setuptools as well, so be it. However, we should
document that it is *not* guaranteed to be available, so projects that need
it should declare the appropriate dependencies and mention "pip install
setuptools" in the appropriate places to ensure it is available

* a "--wheel-only" option for both getpip and pyvenv might be interesting,
if pip gets to a point where it only needs setuptools for source builds and
not installing from wheels. However, for now, I think the PEP should just
assume setuptools will be bundled and installed as a pip dependency. I'm OK
with that - Guido was amenable to adding setuptools to the standard library
back in 2.5 as a case of practicality beating purity. (In retrospect, that
would have just meant setuptools suffered from the same "can't readily be
updated in existing Python versions" problem as distutils, so it's probably
a net positive that PJE eventually decided not to continue with the idea)

Cheers,
Nick.

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