[Python-checkins] peps: Revise PEP 453 to be docs-only for 2.7 & 3.3
nick.coghlan
python-checkins at python.org
Thu Oct 10 16:48:06 CEST 2013
http://hg.python.org/peps/rev/405b80d54b7d
changeset: 5188:405b80d54b7d
user: Nick Coghlan <ncoghlan at gmail.com>
date: Fri Oct 11 00:47:47 2013 +1000
summary:
Revise PEP 453 to be docs-only for 2.7 & 3.3
- all functional changes are now 3.4 only
- still proposes docs changes for 2.7 & 3.3
- notes current effort to create a Windows installer for pip
- notes possibility of a future PEP to provide a combined
CPython 2.7, pip and Python Launcher installer from python.org
files:
pep-0453.txt | 407 ++++++++------------------------------
1 files changed, 89 insertions(+), 318 deletions(-)
diff --git a/pep-0453.txt b/pep-0453.txt
--- a/pep-0453.txt
+++ b/pep-0453.txt
@@ -17,11 +17,11 @@
========
This PEP proposes that the
-`Installing Python Modules <http://docs.python.org/3/install>`__ guide be
-updated to officially recommend the use of ``pip`` as the default
-installer for Python packages, and that appropriate technical changes be
-made in Python 2.7, 3.3 and 3.4 to provide ``pip`` by default in support
-of that recommendation.
+`Installing Python Modules <http://docs.python.org/3/install>`__ guide in
+Python 2.7, 3.3 and 3.4 be updated to officially recommend the use of ``pip``
+as the default installer for Python packages, and that appropriate technical
+changes be made in Python 3.4 to provide ``pip`` by default in support of
+that recommendation.
Rationale
@@ -88,14 +88,11 @@
reference `pip's own bootstrapping instructions
<http://www.pip-installer.org/en/latest/installing.html>`__ rather than
duplicating them. However the user experience created by this approach
-still isn't good (especially on Windows, where downloading and running
-the ``get-pip.py`` bootstrap script with the default OS configuration is
-significantly more painful than downloading and running a binary executable
-or installer). The situation becomes even more complicated when multiple
-Python versions are involved (for example, parallel installations of
-Python 2 and Python 3), since that makes it harder to create and maintain
-good platform specific ``pip`` installers independently of the CPython
-installers.
+still isn't particularly good (although there is an effort under way to
+create a combined Windows installer for ``pip`` and its dependencies that
+should improve matters on that platform, and Mac OS X and *nix platforms
+generally have ``wget`` and hence the ability to easily download and run the
+bootstrap scripts from the command line).
The projects that have decided to forgo dependencies altogether are forced
to either duplicate the efforts of other projects by inventing their own
@@ -233,13 +230,14 @@
of automated testing is weak (or nonexistent), making it difficult to
effectively use the available migration utilities.
-It is quite likely that it is this difference in perspective regarding what
-it means for a version of Python to be "supported" which lies at the heart
-of the long history of conflicts between the developers of Python packaging
-tools and the core development team for CPython. A key goal of this PEP is
-thus to better enable the two groups to collaborate more effectively, by
-using the ``ensurepip`` module as the technical bridge between the two
-distinct software lifecycles and deployment models.
+While this PEP only proposes documentation changes for Python 2.7, once
+``pip`` has a Windows installer available, a separate PEP will be created
+and submitted proposing the creation and distribution of aggregate installers
+for future CPython 2.7 maintenance releases that combine the CPython,
+``pip`` and Python Launcher for Windows installers into a single download
+(the separate downloads would still remain available - the aggregate
+installers would be provided as a convenience, and as a clear indication
+of the recommended operating environment for Python in Windows systems).
Why pip?
@@ -274,15 +272,14 @@
However, to avoid recommending a tool that CPython does not provide, it is
further proposed that the `pip`_ package manager be made available by
-default when installing CPython and when creating virtual environments
-using the standard library's ``venv`` module via the ``pyvenv`` command line
-utility).
+default when installing CPython 3.4 or later and when creating virtual
+environments using the standard library's ``venv`` module via the
+``pyvenv`` command line utility.
To support that end, this PEP proposes the inclusion of an ``ensurepip``
-bootstrapping module in Python 3.4 (along with the upcoming maintenance
-releases of Python 2.7 and 3.3), as well as automatic invocation of that
-module from ``pyvenv`` (for Python 3.4 only), and changes to the way Python
-installed scripts are handled on Windows (also for Python 3.4 only).
+bootstrapping module in Python 3.4, as well as automatic invocation of that
+module from ``pyvenv`` and changes to the way Python installed scripts are
+handled on Windows.
To clearly demarcate development responsibilities, and to avoid
inadvertently downgrading ``pip`` when updating CPython, the proposed
@@ -290,11 +287,12 @@
mechanism in the standard library that is invoked automatically by the
CPython installers provided on python.org.
-To ensure the smoothest possible experience for new users of Python, this
-PEP also proposes that the ``ensurepip`` module and the option to install
-``pip`` when installing CPython be backported to Python 2.7 and 3.3. It
-does *not* propose backporting any changes to ``pyvenv`` (in Python 3.3)
-or to Windows script handling (in either version).
+To provide clear guidance for new users of Python that may not be
+starting with the latest release, this PEP also proposes that the
+"Installing Python Modules" guides in Python 2.7 and 3.3 be updated to
+recommend installing and using ``pip``, rather than invoking ``distutils``
+directly. It does *not* propose backporting any of the code changes that
+are being proposed for Python 3.4.
Finally, the PEP also strongly recommends that CPython redistributors and
other Python implementations ensure that ``pip`` is available by default, or
@@ -387,19 +385,22 @@
options passed to the bootstrap command).
It is proposed that the implementation be carried out in five separate
-steps (all steps after the first are independent of each other and can be
-carried out in any order):
+steps (all steps after the first two are independent of each other and
+can be carried out in any order):
-* the first step would add the ``ensurepip`` module and the private copies
- of the most recently released versions of pip and setuptools, and update
- the "Installing Python Modules" documentation. This change
- would be applied to Python 2.7, 3.3, and 3.4.
-* the Windows installer would be updated to offer the new ``pip``
- installation option for Python 2.7.6, 3.3.3 and 3.4.0.
-* the Mac OS X installer would be updated to offer the new ``pip``
- installation option for Python 2.7.6, 3.3.3 and 3.4.0.
+* the first step would update the "Installing Python Modules" documentation
+ to recommend the use of ``pip`` and reference the ``pip`` team's
+ instructions for downloading and installing it. This change would be
+ applied to Python 2.7, 3.3, and 3.4.
+* the ``ensurepip`` module and the private copies of the most recently
+ released versions of pip and setuptools would be added to Python 3.4
+ and the 3.4 "Installing Python Modules" documentation updated accordingly.
+* the CPython Windows installer would be updated to offer the new ``pip``
+ installation option for Python 3.4.
+* the CPython Mac OS X installer would be updated to offer the new ``pip``
+ installation option for Python 3.4.
* the ``venv`` module and ``pyvenv`` command would be updated to make use
- of ``ensurepip`` in Python 3.4+
+ of ``ensurepip`` in Python 3.4
* the PATH handling and ``sysconfig`` directory layout on Windows would be
updated for Python 3.4+
@@ -432,7 +433,6 @@
* Windows and Mac OS X installations where the "Install pip" option was
*not* chosen during installation
* any installation where the user previously ran "pip uninstall pip"
-* virtual environments created with ``pyvenv`` in Python 3.3
Users that want to retrieve the latest version from PyPI, or otherwise
need more flexibility, can then invoke the extracted ``pip`` appropriately.
@@ -480,21 +480,20 @@
Installing from source
----------------------
-While the prebuilt binary installers will be updated to run
-``python -m ensurepip`` by default, no such change will be made to the
+Just as the prebuilt binary installers will be updated to run
+``python -m ensurepip`` by default, a similar change will be made to the
``make install`` and ``make altinstall`` commands of the source
-distribution.
+distribution. The ``--root`` option passed to the command will be set
+appropriate based on the supplied configuration options.
``ensurepip`` itself (including the private copy of ``pip`` and its
-dependencies) will still be installed normally (as it is a regular
-part of the standard library), only the implicit installation of pip and
-its dependencies will be skipped.
+dependencies) will always be installed normally (as it is a regular
+part of the standard library), but an option will be provided to skip
+the invocation of ``ensurepip``.
-Keeping the pip bootstrapping as a separate step for ``make``-based
-installations should minimize the changes CPython redistributors need to
-make to their build processes. Avoiding the layer of indirection through
-``make`` for the ``ensurepip`` invocation avoids any challenges
-associated with determining where to install the extracted ``pip``.
+This means that even installing from source will provide ``pip`` by default,
+but redistributors provide ``pip`` by other means (or not providing it at
+all) will still be able to opt out of installing it using ``ensurepip``.
Changes to virtual environments
@@ -529,8 +528,8 @@
is available in most virtual environments without additional action on the
part of the end user.
-This particular change will be made only for Python 3.4 and later versions.
-The third-party ``virtualenv`` project will still be needed to obtain a
+As this change will only benefit Python 3.4 and later versions, the
+third-party ``virtualenv`` project will still be needed to obtain a
consistent cross-version experience in Python 3.3 and 2.7.
@@ -539,36 +538,14 @@
The "Installing Python Modules" section of the standard library
documentation in Python 2.7, 3.3 and 3.4 will be updated to recommend
-the use of the bootstrapped ``pip`` installer. It will give a brief
-description of the most common commands and options, but delegate
+the use of the ``pip`` installer, either provided by default in Python 3.4
+or retrieved and installed by the user in Python 2.7 or 3.3. It will give
+a brief description of the most common commands and options, but delegate
to the externally maintained ``pip`` documentation for the full details.
In Python 3.4, the ``pyvenv`` and ``venv`` documentation will also be
updated to reference the revised module installation guide.
-In Python 2.7 and 3.3, the documentation will make clear that the feature
-was added in a maintenance release and users may need to upgrade in order
-to take advantage of it. Specifically, it is proposed to include the
-following warning as a note in the documentation for the ``ensurepip``
-module in these versions (adjust version numbers for 3.3 as appropriate):
-
- This is an optional module, which may not be available in all
- installations of Python 2.7. It is provided solely to simplify the
- process of bootstrapping ``pip`` onto end user's systems. If it is
- not available, please investigate the following alternatives:
-
- * This module was first added in Python 2.7.6. If using an earlier
- maintenance release, it will not be available. If upgrading to
- a more recent maintenance release is not an option, consider
- the alternative bootstrapping mechanisms below.
- * Some platforms provide alternative mechanisms to obtain ``pip``.
- In such cases, the platform documentation should provide
- appropriate details.
- * If upgrading to the latest maintenance release is not feasible, and
- no platform specific instructions are provided, then refer to the
- upstream `pip bootstrapping instructions
- <http://www.pip-installer.org/en/latest/installing.html>`__.
-
The existing content of the module installation guide will be retained in
all versions, but under a new "Invoking distutils directly" subsection.
@@ -645,168 +622,6 @@
releases.
-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". The rationale for doing so in this case is slightly
-different for each of the two versions.
-
-
-Rationale for this policy on maintenance releases
--------------------------------------------------
-
-Python's strict "no new features in maintenance releases" was instituted
-following the introduction of a number of new features over the course of
-the Python 2.2.x series.
-
-Firstly, the ``True`` and ``False`` builtins were added in Python 2.2.1 (at
-the time, they were merely aliases for the values ``1`` and ``0``,
-in Python 2.3 they became instances of the new ``bool`` type and in Python
-3.0 they became true constants recognised by the compiler).
-
-Python 2.2.2 then made the situation worse by adding a new ``chars``
-parameter to the ``lstrip`` and ``rstrip`` string methods, along with an
-entirely new ``zfill`` method. The corresponding changes in the
-``string`` module were not incorporated until Python 2.2.3.
-
-The reason introducing new features in maintenance releases like this is
-problematic is that, except in the cases where code fails due to a bug in
-CPython, developers expect to be able to identify the supported Python
-versions for a library or application solely through the first two
-components of the version number.
-
-The introduction of new builtins and string methods in Python 2.2.1 and
-2.2.2 resulted in many developers claiming Python 2.2 compatibility for
-code that did not in fact run on the original Python 2.2. In effect,
-Python 2.2.2 became the minimum usable version, since there was a
-relatively high chance of code breaking when run on 2.2 (or even 2.2.1).
-
-
-Scope of this proposal
-----------------------
-
-By contrast with the changes that caused such problems during the 2.2.x
-series, this PEP is merely proposing the addition of a new standard
-library module, rather than adding new builtins or changing the interface
-of a builtin type.
-
-The categorical difference between these kinds of changes has already been
-recognised in the Python 3.3 Language Moratorium (PEP 3003), where the
-addition of new builtins was disallowed outright and changes to builtin
-types required an explicit exemption. By contrast, adding new modules was
-explicitly permitted, even while the moratorium was in place.
-
-Furthermore, the proposed ``ensurepip`` module is only a means to the end of
-getting ``pip`` installed on the system. While "upgrade to the latest
-CPython maintenance release" will become the *recommended* approach to
-obtaining ``pip`` for users of Python 2.7 and 3.3 on Windows and Mac OS X
-systems, all of the existing ``pip`` bootstrapping mechanisms will still
-work in cases where upgrading Python isn't a practical alternative.
-
-As described in the documentation update proposal, the ``ensurepip``
-documentation in older releases will include the text explaining how to
-obtain ``pip`` if updating to the latest maintenance release isn't an
-option, or if the module has been removed by a redistributor. This contrasts
-significantly with the changes made during the Python 2.2 series, where they
-were normal additions with no alternatives except to update to a sufficiently
-recent version of Python if a library or application depended on them.
-
-
-Potential consequences of permitting this exemption
----------------------------------------------------
-
-The concern has been expressed that approving an exemption to the "no new
-features in maintenance releases" policy in this case will open the
-flood gates to requests for more such exemptions in the future. It is the
-perspective of the PEP authors that the specific nature of this proposal
-should itself serve to allay those fears.
-
-Firstly, as a proposal to add a new module to the standard library, granting
-an exemption in this case sets no precedent for the more restricted
-categories identified in the PEP 3003 language moratorium.
-
-Secondly, this exemption is requested for a new module that *makes it easy
-to download other modules from PyPI*. If this PEP is accepted, then it can
-be reasonably assumed that modules on PyPI are only a ``pip install`` away
-for most users, with only those users that depend on standard library
-inclusion to make it through corporate compliance reviews still affected
-(and, for many such reviews, inclusion in a future version of the standard
-library will be enough for a backported version to be considered
-acceptable for use).
-
-Making ``pip`` readily available in all versions still under normal
-maintenance thus means that accepting this PEP should have the effect of
-*weakening* the case for any further exemptions to the policy, rather
-than strengthening it.
-
-
-Rationale for permitting the exemption in Python 2.7
-----------------------------------------------------
-
-While Python 3 adoption is proceeding nicely, it remains the case that many
-new users of Python are introduced to Python 2.7 first. This may be
-because their instructors have yet to migrate their courses to Python 3, or
-because they work in an environment where Python 2 is still the preferred
-version, or simply because the frequently adopted approach of writing
-libraries in the common Python 2/3 subset means there are (as of
-September 2013) still more Python 2 only libraries than there are Python 3
-only libraries.
-
-Since one of the primary aims of this PEP is to aid new Python users, it is
-contrary to its spirit to target *only* Python 3.4, when so many users in
-at least the next 12-18 months (where Python 2.7 is still fully supported
-by the core development team) are still going to be introduced to Python
-2 before being introduced to Python 3.
-
-Users first installing Python 2.7 on Windows and Mac OS X following
-acceptance and release of this PEP won't even need to look up how to
-bootstrap ``pip``, since it will already be provided with the CPython
-installer. For those that already have Python installed, but are just
-beginning to explore the PyPI ecosystem, the bootstrapping instructions
-can be simplified to "just install the latest maintenance release of
-CPython".
-
-Making ``pip`` readily available also serves to ease the migration path
-from Python 2 to Python 3, as a number of the standard library additions
-in Python 3 are also available from PyPI for Python 2. Lowering the barrier
-to adoption for these backports makes it easier for current Python 2 users
-to selectively adopt backported Python 3 versions, reducing the number of
-updates needed in any eventual Python 3 migration.
-
-Finally, this PEP solves a serious problem for the ``distutils-sig``
-community, as it means we will finally have a standard mechanism decoupled
-from the standard library's development lifecycle that we can reasonably
-assume to be present on end user's systems (or at least readily
-available) that allows us to support new packaging standards in older
-versions of Python. A tentative, half-hearted endorsement from the
-CPython core development team that tries to hide the existence of the
-pip boostrapping support from end users is unlikely to provide quite the
-same benefits.
-
-
-Rationale for permitting the exemption in Python 3.3
-----------------------------------------------------
-
-The rationale for permitting the exemption in Python 3.3 is admittedly
-not as strong as it is for Python 2.7, as instructors currently using
-Python 3.3 are quite likely to upgrade to Python 3.4 shortly after it is
-released.
-
-In the case of Python 3.3, the rationale is primarily a consistency
-argument, as it permits the recommended ``pip`` bootstrapping instructions
-for both 2.7 and 3.3 to be to upgrade to the latest maintenance version of
-CPython. While existing bootstrapping mechanisms will still be supported,
-the cases where they are needed should be reduced significantly.
-
-Adding the ``ensurepip`` module in Python 3.3 also makes the Python 3.3
-version of the ``pyvenv`` utility far more useful (even without the
-integration proposed for Python 3.4), as it allows users to execute
-``python -m ensurepip`` to bootstrap ``pip`` after activating an
-existing or newly created virtual environment.
-
-
Uninstallation
==============
@@ -842,19 +657,20 @@
- add PythonXY\bin to the Windows PATH (in addition to PythonXY) when the
PATH modification option is enabled during installation
-For Python 2.7 and 3.3, it is proposed that the only change be the one to
-bootstrap ``pip`` by default.
+Note that these changes will only be available in Python 3.4 and later.
-This means that, for Python 3.3, the most reliable way to invoke pip
-globally on Windows (without tinkering manually with PATH) will actually be
+This means that, for Python 3.3, the most reliable way to invoke pip globally
+on Windows (without tinkering manually with PATH) will still remain
``py -m pip`` (or ``py -3 -m pip`` to select the Python 3 version if both
-Python 2 and 3 are installed) rather than simply calling ``pip``.
+Python 2 and 3 are installed) rather than simply calling ``pip``. This
+works because Python 3.3 provides the Python Launcher for
+Windows (and the associated ``py`` command) by default.
For Python 2.7 and 3.2, the most reliable mechanism will be to install the
-standalone Python launcher for Windows and then use ``py -m pip`` as noted
-above.
+Python Launcher for Windows using the standalone installer and then use
+``py -m pip`` as noted above.
-Adding the scripts directory to the system PATH would mean that ``pip``
+Adding the scripts directory to the system PATH will mean that ``pip``
works reliably in the "only one Python installation on the system PATH"
case, with ``py -m pip``, ``pipX``, or ``pipX.Y`` needed only to select a
non-default version in the parallel installation case (and outside a virtual
@@ -900,13 +716,10 @@
installing ``pip`` globally.
* Even if pip is made available globally by other means, do not remove the
- ``ensurepip`` module in Python 3.3 or later.
+ ``ensurepip`` module in Python 3.4 or later.
- * In Python 3.3, ``ensurepip`` will be the recommended way of bootstrapping
- pip in virtual environments created through the ``venv`` module and the
- associated ``pyvenv`` command line tool.
- * Starting with Python 3.4, ``ensurepip`` will be required for automatic
- installation of pip into virtual environments by the ``venv`` module.
+ * ``ensurepip`` will be required for automatic installation of pip into
+ virtual environments by the ``venv`` module.
* This is similar to the existing ``virtualenv`` package for which many
downstream distributors have already made exception to the common
"debundling" policy.
@@ -915,14 +728,6 @@
* However, altering the private copy of pip to remove the embedded
CA certificate bundle and rely on the system CA bundle instead is a
reasonable change.
- * If ``pip`` is made available globally by other means in Python 2.7, then
- it is acceptable (although not desirable) to disable the ``ensurepip``
- module (as the third party ``virtualenv`` distribution is needed to
- create virtual environments in Python 2.7 and ``virtualenv`` already
- ensures ``pip`` is installed into the virtual environments it creates).
- Redistributors that take this course should ensure an appropriate error
- message is displayed if users attempt to import ``ensurepip``, rather
- than simply removing it entirely.
* Ensure that all features of this PEP continue to work with any modifications
made to the redistributed version of Python.
@@ -1018,61 +823,24 @@
Appendix: Rejected Proposals
============================
+Including ensurepip in Python 2.7, and 3.3
+------------------------------------------
-Include pip *only* inside the installers in Python 2.7, and 3.3
----------------------------------------------------------------
+Earlier versions of this PEP made the case that the challenges of getting
+``pip`` bootstrapped for new users posed a significant enough barrier to
+Python's future growth that it justified adding ``ensurepip`` as a new
+feature in the upcoming Python 2.7 and 3.3 maintenance releases.
-An alternative to making an exception to the "no new features" policy in
-Python 2.7 and 3.3 would be to simply bundle pip with the installer and not
-modify the source tree at all. The motivation behind this modification is
-that adding a new feature in a maintenance release is a risky proposition
-and that doing it in this way doesn't violate that policy.
+While the proposal to provide ``pip`` with Python 3.4 was universally
+popular, this part of the proposal was highly controversial and ultimately
+`rejected by MvL as BDFL-Delegate
+<https://mail.python.org/pipermail/python-dev/2013-September/129091.html>`__.
-This has been rejected because:
-
-* It's dubious to declare the binary installers beyond the scope of the
- "no new features in maintenance releases" policy. If the rationale for
- adding this feature to the standard library in a maintenance release isn't
- considered adequate, then it isn't clear why moving that complexity to the
- binary installers should change the verdict.
-* Attempting to hide the existence of the bootstrap module from end users
- makes it more difficult to write updated package installation documentation
- for Python 2.7 and 3.3
-* For 3.3 users that choose to use ``pyvenv`` rather than ``virtualenv``,
- an explicit ``python -m ensurepip`` will be needed to bootstrap ``pip``
- into virtual environments. This can only be documented clearly if the
- module is public
-* Making the bootstrap an installer only feature in Python 2.7 and 3.3
- guarantees the introduction of cross-platform inconsistencies, whereas
- the proposal in this PEP more strongly encourages redistributors to
- offer a more consistent user experience.
-* Making the bootstrap an installer only feature in Python 2.7 and 3.3
- would make it difficult to re-use the bootstrap implementation from 3.4.
-* Making the bootstrap an installer only feature prevents the buildbots
- from being able to run automatic tests against it, which would make
- ensuring that this feature remains working a much more difficult task.
-
-
-Use a different module name in Python 2.7, and 3.3
---------------------------------------------------
-
-Naming the module ``_ensurepip`` in Python 2.7 and 3.3 was considered as
-another means of skirting the "no new features in maintenance releases"
-policy. However, similar to the proposal to only include the new
-feature in the installers rather than the standard library, this feels like
-relying on a technicality to nominally "comply" with the policy, while still
-breaking it in spirit.
-
-It is the considered opinion of the PEP authors that attempting to hide
-the addition of the ``ensurepip`` module in earlier versions will only
-serve to increase confusion rather than to reduce it, so the proposal
-remains to be up front about the fact that the policy is being broken in
-this case, and clearly documenting the rationale for doing so in this PEP.
-
-As noted in the section describing the proposed documentation updates,
-having ``ensurepip`` as a public module in these earlier versions also
-provides a convenient home for the fallback bootstrapping instructions in
-those cases where it *isn't* available.
+Accordingly, the proposal to backport ``ensurepip`` to Python 2.7 and 3.3
+has been removed from this PEP in favour of creating and Windows installer
+for ``pip`` and a possible future PEP suggesting creation of an aggregate
+installer for Python 2.7 that combines CPython 2.7, ``pip`` and the Python
+Launcher for Windows.
Automatically contacting PyPI when bootstrapping pip
@@ -1094,6 +862,9 @@
is now always an explicit separate step, with direct access to the full
pip interface.
+Removing the implicit attempt to access PyPI also made it feasible to
+invoke ``ensurepip`` by default when installing from a custom source build.
+
Implicit bootstrap
------------------
--
Repository URL: http://hg.python.org/peps
More information about the Python-checkins
mailing list