[Python-checkins] peps: PEP 453 updates
nick.coghlan
python-checkins at python.org
Sat Sep 28 14:41:02 CEST 2013
http://hg.python.org/peps/rev/58f33b8eb68d
changeset: 5147:58f33b8eb68d
user: Nick Coghlan <ncoghlan at gmail.com>
date: Sat Sep 28 22:40:33 2013 +1000
summary:
PEP 453 updates
Combined update with changes from both Donald and I
- adjust the abstract to emphasise the fact this is first about
recommending pip as the official installer, and only then
about trying to ensure it is made readily available to users
- note in the rationale that this is a key stepping stone towards
decoupling the release cycle of the language from that of the
PyPI software distribution ecosystem
- expanded proposal overview (including explaining the logic that
leads from recommending pip to providing it by default)
- note the benefit of being able to test the bootstrap using the
existing buildbot fleet
- note the three known use cases for invoking ensurepip directly
- a little more detail on the required documentation updates
- be clear that easy_install *will* be installed by default, but
that problem will go away once pip eliminates their setuptools
dependency
- greatly expand on the rationale for including ensurepip in the
2.7 and 3.3 maintenance releases, including an explanation of
the origins of the current policy in the 2.2.x series, how the
current proposal differs from those, and why this shouldn't
open the floodgates to more requests for exemptions
- mention multiple commercial Python redistributors rather than
just the one
- clarify various issues in the recommendations for downstream
redistributors
- note the licenses for the bundled software
- explain rationale for not making this an installer-only change
in 2.7 and 3.3
- explain rationale for keeping the ensurepip module public in
2.7 and 3.3
- assorted cleanups to grammar and wording
files:
pep-0453.txt | 481 +++++++++++++++++++++++++++++++-------
1 files changed, 383 insertions(+), 98 deletions(-)
diff --git a/pep-0453.txt b/pep-0453.txt
--- a/pep-0453.txt
+++ b/pep-0453.txt
@@ -15,39 +15,24 @@
Abstract
========
-This PEP proposes 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).
-
-To clearly demarcate development responsibilities, and to avoid
-inadvertently downgrading ``pip`` when updating CPython, the proposed
-mechanism to achieve this is to include an explicit `pip`_ bootstrapping
-mechanism in the standard library that is invoked automatically by the
-CPython installers provided on python.org.
-
-The PEP also strongly recommends that CPython redistributors and other Python
-implementations ensure that ``pip`` is available by default, or
-at the very least, explicitly document the fact that it is not included.
-
-
-Proposal
-========
-
-This PEP proposes the inclusion of an ``ensurepip`` bootstrapping module in
-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) directly
-available as part of the standard library. Instead, pip will be a
-bundled application provided along with CPython for the convenience
-of Python users, but subject to its own development life cycle and able
-to be upgraded independently of the core interpreter and standard library.
+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.
Rationale
=========
+This change is considered a necessary step in the evolution of the Python
+packaging ecosystem, as the community has embraced the Python Package Index
+as a mechanism for distributing and installing Python software, but the
+different concerns of language evolution and secure software distribution
+mean that a faster feature release cycle is needed to properly support the
+latter.
+
Currently, on systems without a platform package manager and repository,
installing a third-party Python package into a freshly installed Python
requires first identifying an appropriate package manager and then
@@ -78,11 +63,15 @@
doesn't work. Some operating systems may ease this pain by providing a
global hook that looks for commands that don't exist and suggest an OS
package they can install to make the command work, but that only works
-on systems with platform package managers (such as major Linux
-distributions). No such assistance is available for Windows and
-Mac OS X users. The challenges of dealing with this problem are a
-regular feature of feedback the core Python developers receive from
-professional educators and others introducing new users to Python.
+on systems with platform package managers that include a package that
+provides the relevant cross-platform installer command (such as many major
+Linux distributions). No such assistance is available for Windows and
+Mac OS X users, or more conservative Linux distributions. The challenges
+of dealing with this problem for beginners (who are often also completely
+new to programming, the use of command line tools and editing system
+environment variables) are a regular feature of feedback the core Python
+developers receive from professional educators and others introducing new
+users to Python.
If a project chooses to duplicate the installation instructions and tell
their users how to install the package manager before telling them how to
@@ -114,14 +103,15 @@
duplicated efforts are not automatically updated when upstream releases a new
version.
-By providing a cross-platform package manager by default it will be easier
-for users trying to install these third-party packages as well as easier
-for the people distributing them as they should now be able to safely assume
-that most users will have the appropriate installation tools available.
-This is expected to become more important in the future as the Wheel_
-package format (deliberately) does not have a built in "installer" in the
-form of ``setup.py`` so users wishing to install from a wheel file will want
-an installer even in the simplest cases.
+By officially recommending and providing by default a specific cross-platform
+package manager it will be easier for users trying to install these
+third-party packages as well as easier for the people distributing them as
+they should now be able to safely assume that most users will have the
+appropriate installation tools available (or access to clear instructions on
+how to obtain them). This is expected to become more important in the future
+as the Wheel_ package format (deliberately) does not have a built in
+"installer" in the form of ``setup.py`` so users wishing to install
+from a wheel file will want an installer even in the simplest cases.
Reducing the burden of actually installing a third-party package should
also decrease the pressure to add every useful module to the standard
@@ -143,24 +133,68 @@
Why pip?
--------
-``pip`` has been chosen as the preferred default installer, as it
-addresses several design and user experience issues with its predecessor
-``easy_install`` (these issues can't readily be fixed in ``easy_install``
-itself due to backwards compatibility concerns). ``pip`` is also well suited
-to working within the bounds of a single Python runtime installation
-(including associated virtual environments), which is a desirable feature
-for a tool bundled with CPython.
+``pip`` has been chosen as the preferred default installer, as it is an
+already popular tool that addresses several design and user experience
+issues with its predecessor ``easy_install`` (these issues can't readily
+be fixed in ``easy_install`` itself due to backwards compatibility
+concerns). ``pip`` is also well suited to working within the bounds of
+a single Python runtime installation (including associated virtual
+environments), which is a desirable feature for a tool bundled with CPython.
Other tools like ``zc.buildout`` and ``conda`` are more ambitious in their
aims (and hence substantially better than ``pip`` at handling external
binary dependencies), so it makes sense for the Python ecosystem to treat
-them more like platform package managers to inter operate with rather than
+them more like platform package managers to interoperate with rather than
as the default cross-platform installation tool. This relationship is
similar to that between ``pip`` and platform package management systems
like ``apt`` and ``yum`` (which are also designed to handle arbitrary
binary dependencies).
+Proposal Overview
+=================
+
+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, rather than the current approach of
+recommending the direct invocation of the ``setup.py install`` ``distutils``
+command.
+
+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).
+
+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 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
+mechanism to achieve this is to include an explicit `pip`_ bootstrapping
+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 installer changes and the ``ensurepip`` module
+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).
+
+Finally, the PEP also strongly recommends that CPython redistributors and
+other Python implementations ensure that ``pip`` is available by default, or
+at the very least, explicitly document the fact that it is not included.
+
+This PEP does *not* propose making pip (or any dependencies) directly
+available as part of the standard library. Instead, pip will be a
+bundled application provided along with CPython for the convenience
+of Python users, but subject to its own development life cycle and able
+to be upgraded independently of the core interpreter and standard library.
+
+
Explicit bootstrapping mechanism
================================
@@ -204,6 +238,16 @@
attention to any PyPI related security considerations.
+Reliability considerations
+--------------------------
+
+By including the bootstrap as part of the standard library (rather than
+solely as a feature of the binary installers), the correct operation of
+the bootstrap command can be easily tested using the existing CPython
+buildbot infrastructure rather than adding significantly to the testing
+burden for the installers themselves.
+
+
Implementation strategy
-----------------------
@@ -225,7 +269,7 @@
contact PyPI (instead installing directly from the private wheel files.
Rather than including separate code to handle the bootstrapping, the
-``ensurepip`` module will manipulate sys.path appropriately to allow
+``ensurepip`` module will manipulate ``sys.path`` appropriately to allow
the wheel files to be used to install themselves, either into the current
Python installation or into a virtual environment (as determined by the
options passed to the bootstrap command).
@@ -237,7 +281,7 @@
* 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.
+ 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``
@@ -270,10 +314,16 @@
In most cases, end users won't need to use this CLI directly, as ``pip``
should have been installed automatically when installing Python or when
-creating a virtual environment.
+creating a virtual environment. However, it is formally documented as a
+public interface to support at least these known use cases:
+
+* 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, should invoke the extracted ``pip`` appropriately.
+need more flexibility, can then invoke the extracted ``pip`` appropriately.
Proposed module API
@@ -376,13 +426,20 @@
-------------
The "Installing Python Modules" section of the standard library
-documentation 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 to the externally maintained ``pip``
-documentation for the full details.
+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
+to the externally maintained ``pip`` documentation for the full details.
-The existing content of the module installation guide will be retained,
-but under a new "Invoking distutils directly" subsection.
+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.
+
+The existing content of the module installation guide will be retained in
+all versions, but under a new "Invoking distutils directly" subsection.
Bundling CA certificates with CPython
@@ -421,6 +478,15 @@
``setuptools`` installed first, then the private copy of ``setuptools``
will be removed from ``ensurepip`` in subsequent CPython releases.
+As long as setuptools is needed, it will be a completely unmodified copy of
+the latest upstream setuptools release, including the ``easy_install``
+script if the upstream setuptools continues to include it. The installation
+of ``easy_install`` along with ``pip`` isn't considered desirable, but
+installing a broken setuptools would be worse. This problem will
+naturally resolve itself once the ``pip`` developers have managed to
+eliminate their dependency on ``setuptools`` and the private copy of
+``setuptools`` can be removed entirely from CPython.
+
Updating the private copy of pip
--------------------------------
@@ -431,8 +497,9 @@
After each new ``pip`` release, and again during the preparation for any
release of Python (including feature releases), a script, provided as part
-of this PEP, will be run to ensure the private copies stored in the CPython
-source repository have been updated to the latest versions.
+of the implementation for this PEP, will be run to ensure the private
+copies stored in the CPython source repository have been updated to the
+latest versions.
Updating the ensurepip module API and CLI
@@ -450,27 +517,148 @@
Feature addition in maintenance releases
========================================
-Adding a new module to the standard library in Python 2.7 and 3.3
+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".
+maintenance releases". The rationale for doing so in this case is slightly
+different for each of the two versions.
-It is being proposed in this case as the current bootstrapping issues for
-the third-party Python package ecosystem 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 change should aid the vast majority of current Python users, rather
-than only those with the freedom to adopt Python 3.4 as soon as it is
+Rationale for the policy
+------------------------
+
+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.
+
+
+Potential consequences of permitting this exemption
+---------------------------------------------------
+
+There is some legitimate concern 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 the primary purpose 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 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 improve the usability of
+Python 2.7 itself, as a number of the standard library additions in Python
+3 are also available from PyPI for Python 2.
+
+
+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
==============
-No changes are proposed to the uninstallation process by this PEP. The
-bootstrapped pip will be installed the same way as any other pip
+No changes are proposed to the CPython uninstallation process by this PEP.
+The bootstrapped pip will be installed the same way as any other pip
installed packages, and will be handled in the same way as any other
post-install additions to the Python environment.
@@ -501,11 +689,11 @@
- 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.
+For Python 2.7 and 3.3, it is proposed that the only change be the one to
+bootstrap ``pip`` by default.
-This means that, for Python 3.3, the most reliable way to invoke pip 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 actually be
``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``.
@@ -533,29 +721,39 @@
A common source of Python installations are through downstream distributors
such as the various Linux Distributions [#ubuntu]_ [#debian]_ [#fedora]_, OSX
-package managers [#homebrew]_ [#macports]_ [#fink]_, 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:
+package managers [#homebrew]_ [#macports]_ [#fink]_, and commercial Python
+redistributors [#ContinuumIO]_ [#ActiveState]_ [#Enthought]_. In order to
+provide a consistent, user-friendly experience to all users of Python
+regardless of how they obtained Python this PEP recommends and asks that
+downstream distributors:
-* Ensure that whenever Python is installed pip is also installed.
+* Ensure that whenever Python is installed ``pip`` is either installed or is
+ otherwise made readily available to end users.
- * 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.
+ * For redistributors using binary installers, this may take the form of
+ optionally executing the ``ensurepip`` bootstrap during installation,
+ similar to the CPython installers.
+ * For redistributors using package management systems, it 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.
* Another reasonable way to implement this is to package pip separately but
ensure that there is some sort of global hook that will recommend
installing the separate pip package when a user executes ``pip`` without
it being installed. Systems that choose this option should ensure that
- the ``pyvenv`` command still installs pip into the virtual environment
- by default, but may modify the ``ensurepip`` module in the system Python
+ the ``ensurepip`` module still installs pip directly when invoked inside
+ a virtual environment, but may modify the module in the system Python
installation to redirect to the platform provided mechanism when
installing ``pip`` globally.
-* Do not remove the bundled copy of pip.
+* Even if pip is made available globally by other means, do not remove the
+ ``ensurepip`` module in Python 3.3 or later.
- * This is required for installation of pip into a virtual environment by the
- ``venv`` module.
+ * 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.
* This is similar to the existing ``virtualenv`` package for which many
downstream distributors have already made exception to the common
"debundling" policy.
@@ -564,12 +762,14 @@
* 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.
-
-* Migrate build systems to utilize `pip`_ and `Wheel`_ instead of directly
- using ``setup.py``.
-
- * This will ensure that downstream packages can more easily utilize the
- new metadata formats which may not have a ``setup.py``.
+ * 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.
@@ -581,10 +781,17 @@
* ``pip install --upgrade pip`` in a global installation should not affect
any already created virtual environments (but is permitted to affect
future virtual environments, even though it will not do so when using
- the upstream version of ``ensurepip``).
+ the standard implementation of ``ensurepip``).
* ``pip install --upgrade pip`` in a virtual environment should not affect
the global installation.
+* Migrate build systems to utilize `pip`_ and `Wheel`_ wherever feasible
+ and avoid directly invoking ``setup.py``.
+
+ * This isn't strictly required by this PEP, but will help ensure a
+ smoother and more timely adoption of improved metadata formats as the
+ Python packaging ecosystem continues to evolve.
+
In the event that a Python redistributor chooses *not* to follow these
recommendations, we request that they explicitly document this fact and
provide their users with suitable guidance on translating upstream ``pip``
@@ -631,10 +838,86 @@
``pip``.
+Licensing
+---------
+
+``pip`` is currently licensed as 1 Clause BSD, and it contains code taken
+from other projects. Additionally this PEP will include setuptools until
+such time as pip no longer requires it. The licenses for these appear in
+the table below.
+
+================= ============
+ Project License
+================= ============
+requests Apache 2.0
+six 1 Clause BSD
+html5lib 1 Clause BSD
+distlib PSF
+colorama 3 Clause BSD
+Mozilla CA Bundle LGPL
+setuptools PSF
+================= ============
+
+All of these licenses should be compatible with the PSF license. Additionally
+it is unclear if a CA Bundle is copyrightable material and thus if it needs
+or can be licensed at all.
+
+
Appendix: Rejected Proposals
============================
+Include pip *only* inside the installers in Python 2.7, and 3.3
+---------------------------------------------------------------
+
+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.
+
+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 "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.
+
+
Automatically contacting PyPI when bootstrapping pip
----------------------------------------------------
@@ -754,7 +1037,9 @@
.. [#homebrew] `Homebrew <http://brew.sh/>`
.. [#macports] `MacPorts <http://macports.org>`
.. [#fink] `Fink <http://finkproject.org>`
-.. [#conda] `Conda <http://www.continuum.io/blog/conda>`
+.. [#ContinuumIO] `Anaconda <https://store.continuum.io/cshop/anaconda/>`
+.. [#ActiveState] `ActivePython <http://www.activestate.com/activepython>`
+.. [#Enthought] `Enthought Canopy <https://www.enthought.com/products/canopy/>`
Copyright
=========
--
Repository URL: http://hg.python.org/peps
More information about the Python-checkins
mailing list