peps: 405b80d54b7d (original) (raw)

--- a/pep-0453.txt +++ b/pep-0453.txt @@ -17,11 +17,11 @@ Abstract ======== 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 @@ This specific problem can be partially a reference pip's own bootstrapping instructions[](#l1.21) <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 @@ based infrastructure to Python 3, especi 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 @@ recommending the direct invocation of th 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 to achieve this is to include 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 @@ Python installation or into a virtual en 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

-

- 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 @@ the extracted pip may offer addition 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 @@ during installation, this PEP proposes t