Abstract

This PEP proposes that theensurepip module, added to Python 3.4 by PEP453, be backported to Python 2.7. It also proposes that automatic invocationofensurepip be added to the Python 2.7 Windows and OSX installers. Howeverit doesnot propose that automatic invocation be added to theMakefile.

It also proposes that the documentation changes for the package distributionand installation guides be updated to match that in 3.4, which references usingtheensurepip module to bootstrap the installer.

Rationale

Python 2.7 is effectively a LTS release of Python which represents the end ofthe 2.x series and there is still a very large contingent of users whom arestill using Python 2.7 as their primary version. These users, in order toparticipate in the wider Python ecosystem, must manually attempt to go out andfind the correct way to bootstrap the packaging tools.

It is the opinion of this PEP that making it as easy as possible for end usersto participate in the wider Python ecosystem is important for 3 primaryreasons:

1. The Python 2.x to 3.x migration has a number of painpoints that are eased bya number of third party modules such as six[1], modernize[2],or future[3]. However relying on these tools requires that everyonewho uses the project have a tool to install these packages.
2. In addition to tooling to aid in migration from Python 2.x to 3.x, there arealso a number of modules that arenew in Python 3 for which there arebackports available on PyPI. This can also aid in the ability for peopleto write 2.x and 3.x compatible software as well as enable them to use someof the newer features of Python 3 on Python 2.
3. Users also will need a number of tools in order to create python packagesthat conform to the newer standards that are being proposed. Things likesetuptools[4], Wheel[5], and twine[6] are enablinga safer, faster, and more reliable packaging tool chain. These tools can bedifficult for people to use if first they must be told how to go out andinstall the package manager.
4. One of Pythons biggest strengths is in the huge ecosystem of libraries andprojects that have been built on top of it, most of which are distributedthrough PyPI. However, in order to benefit from this wide ecosystemmeaningfully requires end users, some of which are going to be new, to makea decision on which package manager they should get, how to get it, and thenfinally actually installing it first.

Furthermore, alternative implementations of Python are recognizing the benefitsofPEP 453 and both PyPy and Jython have plans to backport ensurepip to their2.7 runtimes.

Automatic Invocation

PEP 453 hasensurepip automatically invoked by default in theMakefileand the Windows and OSX Installers. This allowed it to ensure that, by default,all users would get Python with pip already installed. This PEP howeverbelieves that while this is fine for the Python 2.7 Windows and Mac OS Xinstallers it isnot ok for the Python 2.7Makefile in general.

The primary consumers of theMakefile are downstream package managers whichdistribute Python themselves. These downstream distributors typically do notwant pip to be installed viaensurepip and would prefer that end usersinstall it with their own package manager. Not invokingensurepipautomatically from theMakefile would allow these distributors to simplyignore the fact thatensurepip has been backported and still not end upwith pip installed via it.

The primary consumers of the OSX and Windows installers are end users who areattempting to install Python on their own machine. There is not a packagemanager available where these users can install pip into their Python througha more supported mechanism. For this reason it is the belief of this PEP thatinstalling by default on OSX and Windows is the best course of action.

Documentation

As part of this PEP, the updated packaging distribution and installationguides for Python 3.4 would be backported to Python 2.7.

Disabling ensurepip by Downstream Distributors

Due to its use in thevenv module, downstream distributors cannot disabletheensurepip module in Python 3.4. However, since Python 2.7 has no suchmodule it is explicitly allowed for downstream distributors to patch theensurepip module to prevent it from installing anything.

If a downstream distributor wishes to disableensurepip completely inPython 2.7, they should still at least provide the module and allowpython-mensurepip style invocation. However it should raise errors orotherwise exit with a non-zero exit code and print out an error on stderrdirecting users to what they can/should use instead ofensurepip.

References

Copyright

This document has been placed in the public domain.