diff --git a/pep-0453.txt b/pep-0453.txt index 82a72647d..2848430cb 100644 --- a/pep-0453.txt +++ b/pep-0453.txt @@ -15,39 +15,24 @@ Post-History: 30-Aug-2013, 15-Sep-2013, 18-Sep-2013, 19-Sep-2013, 23-Sep-2013 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 `__ 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 @@ users may get a confusing error message when the installation command 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 @@ leaving users vulnerable to security issues because the included code or 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 @@ these utilities. 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 `__ 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 @@ Only users that choose to use ``pip`` directly will need to pay 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 @@ to include private copies of ``pip`` and ``setuptools`` as wheel files 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 @@ 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. + 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 @@ options:: 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 @@ Documentation ------------- 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 @@ Once pip is able to run ``pip install --upgrade pip`` without needing ``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 @@ regularly updated to the latest versions of everything it bootstraps. 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 @@ releases. 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 @@ during installation, this PEP proposes that the Windows installer (and - 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 @@ Recommendations for Downstream Distributors 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 @@ asks that downstream distributors: * 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 @@ asks that downstream distributors: * ``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 @@ warrants a security release of CPython with an updated private copy of ``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 @@ References .. [#homebrew] `Homebrew ` .. [#macports] `MacPorts ` .. [#fink] `Fink ` -.. [#conda] `Conda ` +.. [#ContinuumIO] `Anaconda ` +.. [#ActiveState] `ActivePython ` +.. [#Enthought] `Enthought Canopy ` Copyright =========