Add 3.3 and 2.7 back to pip boostrap PEP
Donald reminded me of both why we originally proposed that, and how the current implementation supports older Python versions
This commit is contained in:
parent
c2acda1c65
commit
e142f3e4a1
57
pep-0453.txt
57
pep-0453.txt
|
@ -26,7 +26,8 @@ Proposal
|
|||
========
|
||||
|
||||
This PEP proposes the inclusion of a ``getpip`` bootstrapping module in
|
||||
Python 3.4.
|
||||
Python 3.4, as well as in the next maintenance releases of Python 3.3 and
|
||||
2.7.
|
||||
|
||||
This PEP does *not* propose making pip (or any dependencies) part of the
|
||||
standard library. Instead, pip will be a bundled application provided
|
||||
|
@ -203,6 +204,28 @@ This means that maintenance releases of the CPython installers will include
|
|||
an updated version of the ``getpip`` bootstrap module.
|
||||
|
||||
|
||||
Feature Addition in Maintenance Releases
|
||||
========================================
|
||||
|
||||
Adding a new module to the standard library in Python 2.7 and 3.3
|
||||
maintenance releases breaks the usual policy of "no new features in
|
||||
maintenance releases".
|
||||
|
||||
It is being proposed in this case as the bootstrapping problem greatly
|
||||
affects the experience of new users, especially on Python 2 where many
|
||||
Python 3 standard library improvements are available as backports on PyPI,
|
||||
but are not included in the Python 2 standard library.
|
||||
|
||||
By updating Python 2.7, 3.3 and 3.4 to easily bootstrap the PyPI ecosystem,
|
||||
this should aid the vast majority of Python users, rather than only those
|
||||
with the freedom to adopt Python 3.4 as soon as it is released.
|
||||
|
||||
This is also a matter of starting as we mean to continue: similar to IDLE
|
||||
(see PEP 434), ``getpip`` will be permanently exempted from the "no new
|
||||
features in maintenance releases" restriction, as it will include (and
|
||||
rely on) upgraded versions of ``pip`` even in maintenance releases.
|
||||
|
||||
|
||||
Pre-installation
|
||||
================
|
||||
|
||||
|
@ -216,7 +239,8 @@ 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. Note
|
||||
that ``getpip`` itself will still be installed normally (as it is a regular
|
||||
part of the standard library), only
|
||||
part of the standard library), only the installation of pip and its
|
||||
dependencies will be skipped.
|
||||
|
||||
Keeping the pip bootstrapping as a separate step for make based
|
||||
installations should minimize the changes CPython redistributors need to
|
||||
|
@ -284,6 +308,18 @@ use of the bundled ``pip`` rather than retrieving the latest version from
|
|||
PyPI.
|
||||
|
||||
|
||||
Bundling CA Certificates with CPython
|
||||
=====================================
|
||||
|
||||
The reference ``getpip`` implementation includes the ``pip`` CA
|
||||
bundle along with the rest of pip. This means CPython effectively includes
|
||||
a CA bundle that is used solely for ``getpip``.
|
||||
|
||||
This is considered desirable, as it ensures that ``pip`` will behave the
|
||||
same across all supported versions of Python, even those prior to Python
|
||||
3.4 that cannot access the system certificate store on Windows.
|
||||
|
||||
|
||||
Recommendations for Downstream Distributors
|
||||
===========================================
|
||||
|
||||
|
@ -308,6 +344,9 @@ downstream distributors:
|
|||
"debundling" policy.
|
||||
* This does mean that if ``pip`` needs to be updated due to a security
|
||||
issue, so does the bundled version in the ``getpip`` bootstrap module
|
||||
* However, altering the bundled version of pip to remove the embedded
|
||||
CA certificate bundle and rely the system CA bundle instead is a
|
||||
reasonable change.
|
||||
|
||||
* Migrate build systems to utilize `pip`_ and `Wheel`_ instead of directly
|
||||
using ``setup.py``.
|
||||
|
@ -365,20 +404,6 @@ Appendix: Rejected Proposals
|
|||
============================
|
||||
|
||||
|
||||
Bundling the installer in Python 2.7 and 3.3 Maintenance Releases
|
||||
-----------------------------------------------------------------
|
||||
|
||||
Unlike earlier Python versions, Python 3.4 provides access to the system
|
||||
certificate store on Windows systems. This allows ``getpip`` to create a
|
||||
verified connection to PyPI without needing to include a custom certificate
|
||||
bundle with CPython.
|
||||
|
||||
Rather than trying to come up with a secure bootstrapping alternative for
|
||||
earlier Python versions, the existing manual bootstrapping mechanism (which
|
||||
relies on SSL verification in other tools like curl, wget and web browsers)
|
||||
will continue to be used.
|
||||
|
||||
|
||||
Implicit Bootstrap
|
||||
------------------
|
||||
|
||||
|
|
Loading…
Reference in New Issue