This PEP proposes that theInstalling Python Modules guide inPython 2.7, 3.3 and 3.4 be updated to officially recommend the use ofpipas the default installer for Python packages, and that appropriate technicalchanges be made in Python 3.4 to providepip by default in support ofthat recommendation.
This PEP was accepted for inclusion in Python 3.4 by Martin von Löwis onTuesday 22nd October, 2013.
Issue 19347 has been created totrack the implementation of this PEP.
There are two related, but distinct rationales for the proposal in thisPEP. The first relates to the experience of new users, while the secondrelates to better enabling the evolution of the broader Python packagingecosystem.
Currently, on systems without a platform package manager and repository,installing a third-party Python package into a freshly installed Pythonrequires first identifying an appropriate package manager and theninstalling it.
Even on systems thatdo have a platform package manager, it is unlikely toinclude every package that is available on the Python Package Index, andeven when a desired third-party package is available, the correct name inthe platform package manager may not be clear.
This means that, to work effectively with the Python Package Indexecosystem, users must know which package manager to install, where to getit, and how to install it. The effect of this is that third-party Pythonprojects are currently required to choose from a variety of undesirablealternatives:
All of these available options have significant drawbacks.
If a project simply assumes a user already has the tooling then beginningusers may get a confusing error message when the installation commanddoesn’t work. Some operating systems may ease this pain by providing aglobal hook that looks for commands that don’t exist and suggest an OSpackage they can install to make the command work, but that only workson systems with platform package managers that include a package thatprovides the relevant cross-platform installer command (such as many majorLinux distributions). No such assistance is available for Windows andMac OS X users, or more conservative Linux distributions. The challengesof dealing with this problem for beginners (who are often also completelynew to programming, the use of command line tools and editing systemenvironment variables) are a regular feature of feedback the core Pythondevelopers receive from professional educators and others introducing newusers to Python.
If a project chooses to duplicate the installation instructions and telltheir users how to install the package manager before telling them how toinstall their own project then whenever these instructions need updatesthey need updating by every project that has duplicated them. This isparticular problematic when there are multiple competing installationtools available, and different projects recommend different tools.
This specific problem can be partially alleviated by strongly promotingpip as the default installer and recommending that other projectsreferencepip’s own bootstrapping instructions rather thanduplicating them. However the user experience created by this approachstill isn’t particularly good (although there is an effort under way tocreate a combined Windows installer forpip and its dependencies thatshould improve matters on that platform, and Mac OS X and *nix platformsgenerally havewget and hence the ability to easily download and run thebootstrap scripts from the command line).
The projects that have decided to forgo dependencies altogether are forcedto either duplicate the efforts of other projects by inventing their ownsolutions to problems or are required to simply include the other projectsin their own source trees. Both of these options present their own problemseither in duplicating maintenance work across the ecosystem or potentiallyleaving users vulnerable to security issues because the included code orduplicated efforts are not automatically updated when upstream releases a newversion.
By officially recommending and providing by default a specific cross-platformpackage manager it will be easier for users trying to install thesethird-party packages as well as easier for the people distributing them asthey should now be able to safely assume that most users will have theappropriate installation tools available (or access to clear instructions onhow to obtain them). This is expected to become more important in the futureas theWheel package format (deliberately) does not have a built in“installer” in the form ofsetup.py so users wishing to installfrom a wheel file will want an installer even in the simplest cases.
Reducing the burden of actually installing a third-party package shouldalso decrease the pressure to add every useful module to the standardlibrary. This will allow additions to the standard library to focus moreon why Python should have a particular tool out of the box, and why itis reasonable for that package to adopt the standard library’s 18-24 monthfeature release cycle, instead of using the general difficulty of installingthird-party packages as justification for inclusion.
Providing a standard installation system also helps with bootstrappingalternate build and installer systems, such aszc.buildout,hashdistandconda. So long aspipinstall<tool> works, then a standardPython-specific installer provides a reasonably secure, cross platformmechanism to get access to these utilities.
As no new packaging standard can achieve widespread adoption without atransition strategy that covers the versions of Python that are inwidespreadcurrent use (rather than merely future versions, like mostlanguage features), the change proposed in this PEP is considered anecessary step in the evolution of the Python packaging ecosystem
The broader community has embraced the Python Package Index as a mechanismfor distributing and installing Python software, but the different concernsof language evolution and secure software distribution mean that a fasterfeature release cycle that encompasses older versions is needed to properlysupport the latter.
In addition, the core CPython development team have the luxury ofdropping support for earlier Python versions well before the rest of thecommunity, as downstream commercial redistributors pick up the task ofproviding support for those versions to users that still need it, whilemany third party libraries maintain compatibility with those versions aslong as they remain in widespread use.
This means that the currentsetup.pyinstall based model for packageinstallation poses serious difficulties for the development and adoptionof new packaging standards, as, depending on how a project writes theirsetup.py file, the installation command (along with other operations)may end up invoking the standard library’sdistutils package.
As an indicator of how this may cause problems for the broader ecosystem,consider that the feature set ofdistutils in Python 2.6 was frozenin June 2008 (with the release of Python 2.6b1), while the feature set ofdistutils in Python 2.7 was frozen in April 2010 (with the release ofPython 2.7b1).
By contrast, using a separate installer application likepip (whichensures that evensetup.py files that invokedistutils directlystill support the new packaging standards) makes it possible to supportnew packaging standards in older versions of Python, just by upgradingpip (which receives new feature releases roughly every 6 months). Thesituation on older versions of Python is further improved by making iteasier for end users to install and upgrade newer build systems likesetuptools or improved PyPI upload utilities liketwine.
It is not coincidental that this proposed model of using a separate installerprogram with more metadata heavy and less active distribution formats matchesthat used by most operating systems (including Windows since the introductionof the installer service and the MSI file format), as well as many otherlanguage specific installers.
For Python 2.6, this compatibility issue is largely limited to variousenterprise Linux distributions (and their downstream derivatives). Thesedistributions often have even slower update cycles than CPython, so theyoffer full support for versions of Python that are considered “securityfix only” versions upstream (and sometimes may even be to the point wherethe core development team no longer support them at all - you can still getcommercial support for Python 2.3 if you really need it!).
In practice, the fact that tools likewget andcurl are readilyavailable on Linux systems, that most users of Python on Linux arealready familiar with the command line, and that most Linux distributionsship with a default configuration that makes running Python scripts easy,means that the existingpip bootstrapping instructions for any *nixsystem are already quite straightforward. Even ifpip isn’t provided bythe system package manager, then usingwget orcurl to retrieve thebootstrap script from www.pip-installer.org and then running it is just acouple of shell commands that can easily be copied and pasted as necessary.
Accordingly, for any version of Python on any *nix system, the need tobootstrappip in older versions isn’t considered a major barrier toadoption of new packaging standards, since it’s just one more smallspeedbump encountered by users of these long term stable releases. For*nix systems, this PEP’s formal endorsement ofpip as the preferreddefault packaging tool is seen as more important than the underlyingtechnical details involved in makingpip available by default, sinceit shifts the nature of the conversation between the developers ofpipand downstream repackagers of bothpip and CPython.
For Python 2.7, on the other hand, the compatibility issue for adopting newmetadata standards is far more widespread, as it affects the python.orgbinary installers for Windows and Mac OS X, as well as even relativelyfast moving *nix platforms.
Firstly, and unlike Python 2.6, Python 2.7 is still a fully supportedupstream version, and will remain so until the release of Python 2.7.9(currently scheduled for May 2015), at which time it is expected to enterthe usual “security fix only” mode. That means there are at least another19 months where Python 2.7 is a deployment target for Python applicationsthat enjoys full upstream support. Even after the core development teamswitches 2.7 to security release only mode in 2015, Python 2.7 will likelyremain a commercially supported legacy target out beyond 2020.
While Python 3 already presents a compelling alternative over Python 2 fornew Python applications and deployments without an existing investmentin Python 2 and without a dependency on specific Python 2 only third partymodules (a set which is getting ever smaller over time), it is going to takelonger to create compelling business cases to update existing Python 2.7based infrastructure to Python 3, especially in situations where the cultureof automated testing is weak (or nonexistent), making it difficult toeffectively use the available migration utilities.
While this PEP only proposes documentation changes for Python 2.7, oncepip has a Windows installer available, a separate PEP will be createdand submitted proposing the creation and distribution of aggregate installersfor 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 aggregateinstallers would be provided as a convenience, and as a clear indicationof the recommended operating environment for Python in Windows systems).
pip has been chosen as the preferred default installer, as it is analready popular tool that addresses several design and user experienceissues with its predecessoreasy_install (these issues can’t readilybe fixed ineasy_install itself due to backwards compatibilityconcerns).pip is also well suited to working within the bounds ofa single Python runtime installation (including associated virtualenvironments), which is a desirable feature for a tool bundled with CPython.
Other tools likezc.buildout andconda are more ambitious in theiraims (and hence substantially better thanpip at handling externalbinary dependencies), so it makes sense for the Python ecosystem to treatthem more like platform package managers to interoperate with rather thanas the default cross-platform installation tool. This relationship issimilar to that betweenpip and platform package management systemslikeapt andyum (which are also designed to handle arbitrarybinary dependencies).
This PEP proposes that theInstalling Python Modules guide beupdated to officially recommend the use ofpip as the defaultinstaller for Python packages, rather than the current approach ofrecommending the direct invocation of thesetup.pyinstall command.
However, to avoid recommending a tool that CPython does not provide, it isfurther proposed that thepip package manager be made available bydefault when installing CPython 3.4 or later and when creating virtualenvironments using the standard library’svenv module via thepyvenv command line utility.
To support that end, this PEP proposes the inclusion of anensurepipbootstrapping module in Python 3.4, as well as automatic invocation of thatmodule frompyvenv and changes to the way Python installed scripts arehandled on Windows. Using a bootstrap module rather than providingpipdirectly helps to clearly demarcate development responsibilities, and toavoid inadvertently downgradingpip when updating CPython.
To provide clear guidance for new users of Python that may not bestarting with the latest release, this PEP also proposes that the“Installing Python Modules” guides in Python 2.7 and 3.3 be updated torecommend installing and usingpip, rather than invokingdistutilsdirectly. It doesnot propose backporting any of the code changes thatare being proposed for Python 3.4.
Finally, the PEP also strongly recommends that CPython redistributors andother Python implementations ensure thatpip is available by default, orat the very least, explicitly document the fact that it is not included.
This PEP doesnot propose making pip (or any dependencies) directlyavailable as part of the standard library. Instead, pip will be abundled application provided along with CPython for the convenienceof Python users, but subject to its own development life cycle and ableto be upgraded independently of the core interpreter and standard library.
An additional module calledensurepip will be added to the standardlibrary whose purpose is to install pip and any of its dependencies into theappropriate location (most commonly site-packages). It will expose acallable namedbootstrap() as well as offer direct execution viapython-mensurepip.
The bootstrap willnot contact PyPI, but instead rely on a private copyof pip stored inside the standard library. Accordingly, only optionsrelated to the installation location will be supported (--user,--root, etc).
It is considered desirable that users be strongly encouraged to use thelatest available version ofpip, in order to take advantage of theongoing efforts to improve the security of the PyPI based ecosystem, aswell as benefiting from the efforts to improve the speed, reliability andflexibility of that ecosystem.
In order to satisfy this goal of providing the most recent version ofpip by default, the private copy ofpip will be updated in CPythonmaintenance releases, which should align well with the 6-month cycle usedfor newpip releases.
The design in this PEP has been deliberately chosen to avoid making anysignificant changes to the trust model of CPython for end users that donot subsequently run the commandpipinstall--upgradepip.
The installers will contain all the components of a fully functioningversion of Python, including thepip installer. The installationprocess willnot require network access, and willnot rely ontrusting the security of the network connection established betweenpip and the Python package index.
Only users that choose to usepip to communicate with PyPI willneed to pay attention to the additional security considerations that comewith doing so.
However, the core CPython team will still assist with reviewing andresolving at least thecertificate update management issue currentlyaffecting therequests project (and hencepip), and may also beable to offer assistance in resolving other identified security concerns[1].
By including the bootstrap as part of the standard library (rather thansolely as a feature of the binary installers), the correct operation ofthe bootstrap command can be easily tested using the existing CPythonbuildbot infrastructure rather than adding significantly to the testingburden for the installers themselves.
To ensure there is no need for network access when installing Python orcreating virtual environments, theensurepip module will, as animplementation detail, include a complete private copy of pip and itsdependencies which will be used to extract pip and install it into the targetenvironment. It is important to stress that this private copy of pip isonly an implementation detail and it shouldnot be relied on orassumed to exist beyond the public capabilities exposed through theensurepip module (and indirectly throughvenv).
There is not yet a referenceensurepip implementation. The existingget-pip.py bootstrap script demonstrates an earlier variation of thegeneral concept, but the standard library version would take advantage ofthe improved distribution capabilities offered by the CPython installersto include private copies ofpip andsetuptools as wheel files(rather than as embedded base64 encoded data), and would not try tocontact PyPI (instead installing directly from the private wheel files).
Rather than including separate code to handle the bootstrapping, theensurepip module will manipulatesys.path appropriately to allowthe wheel files to be used to install themselves, either into the currentPython installation or into a virtual environment (as determined by theoptions passed to the bootstrap command).
It is proposed that the implementation be carried out in five separatesteps (all steps after the first two are independent of each other andcan be carried out in any order):
pip and reference thepip team’sinstructions for downloading and installing it. This change would beapplied to Python 2.7, 3.3, and 3.4.ensurepip module and the private copies of the most recentlyreleased versions of pip and setuptools would be added to Python 3.4and the 3.4 “Installing Python Modules” documentation updated accordingly.pipinstallation option for Python 3.4.pipinstallation option for Python 3.4.venv module andpyvenv command would be updated to make useofensurepip in Python 3.4If this PEP is accepted, the proposed time frame for integration ofpipinto the CPython release is as follows:
ensurepip implemented based on apre-release version ofpip 1.5.ensurepip.ensurepip updated to use apip 1.5 release candidate.pip is upto date.requests certificate management issue resolvedensurepip updated to the final release ofpip 1.5, or asubsequent maintenance release (including a suitably updated vendoredcopy ofrequests)(SeePEP 429 for the current official scheduled dates of each release. Dateslisted above are accurate as of October 20th, 2013.)
If there is no final or maintenance release ofpip 1.5 with a suitableupdated version ofrequests available by one week before the scheduledPython 3.4 beta 2 release, then implementation of this PEP willbe deferred to Python 3.5. Note that this scenario is considered unlikely -the tentative date for thepip 1.5 release is currently December 1st.
In future CPython releases, this kind of coordinated scheduling shouldn’t beneeded: the CPython release manager will be able to just update to the latestreleased version ofpip. However, in this case, some fixes are needed inpip in order to allow the bundling to work correctly, and thecertificate update mechanism forrequests needs to be improved, so thepip 1.5 release cycle needs to be properly aligned with the CPython 3.4beta releases.
The proposed CLI is based on a subset of the existingpipinstalloptions:
Usage:python-mensurepip[options]GeneralOptions:-h,--helpShowhelp.-v,--verboseGivemoreoutput.Optionisadditive,andcanbeusedupto3times.-V,--versionShowthepipversionthatwouldbeextractedandexit.-q,--quietGivelessoutput.InstallationOptions:-U,--upgradeUpgradepipanddependencies,evenifalreadyinstalled--userInstallusingtheuserscheme.--root<dir>Installeverythingrelativetothisalternaterootdirectory.
In most cases, end users won’t need to use this CLI directly, aspipshould have been installed automatically when installing Python or whencreating a virtual environment. However, it is formally documented as apublic interface to support at least these known use cases:
Users that want to retrieve the latest version from PyPI, or otherwiseneed more flexibility, can then invoke the extractedpip appropriately.
The proposedensurepip module API consists of the following twofunctions:
defversion():""" Returns a string specifying the bundled version of pip. """defbootstrap(root=None,upgrade=False,user=False,verbosity=0):""" Bootstrap pip into the current Python installation (or the given root directory). """
The CPython Windows and Mac OS X installers will each gain a new option:
This option will be checked by default.
If the option is checked, then the installer will invoke the followingcommand with the just installed Python:
python-mensurepip--upgrade
This ensures that, by default, installing or updating CPython will ensurethat the installed version of pip is at least as recent as the one includedwith that version of CPython. If a newer version of pip has already beeninstalled thenpython-mensurepip--upgrade will simply return withoutdoing anything.
Just as the prebuilt binary installers will be updated to runpython-mensurepip by default, a similar change will be made to themakeinstall andmakealtinstall commands of the sourcedistribution. The directory settings in thesysconfig module shouldensure thepip components are automatically installed to the expectedlocations.
ensurepip itself (including the private copy ofpip and itsdependencies) will always be installed normally (as it is a regularpart of the standard library), but an option will be provided to skipthe invocation ofensurepip.
This means that even installing from source will providepip by default,but redistributors providepip by other means (or not providing it atall) will still be able to opt out of installing it usingensurepip.
Python 3.3 included a standard library approach to virtual Python environmentsthrough thevenv module. Since its release it has become clear that veryfew users have been willing to use this feature directly, in part due to thelack of an installer present by default inside of the virtual environment.They have instead opted to continue using thevirtualenv package whichdoes include pip installed by default.
To make thevenv more useful to users it will be modified to issue thepip bootstrap by default inside of the new environment while creating it. Thiswill allow people the same convenience inside of the virtual environment asthis PEP provides outside of it as well as bringing thevenv module closerto feature parity with the externalvirtualenv package, making it a moresuitable replacement.
To handle cases where a user does not wish to have pip bootstrapped intotheir virtual environment a--without-pip option will beadded.
Thevenv.EnvBuilder andvenv.create APIs will be updated to acceptone new parameter:with_pip (defaulting toFalse).
The new default for the module API is chosen for backwards compatibilitywith the current behaviour (as it is assumed that most invocation of thevenv module happens through third part tools that likely will notwantpip installed without explicitly requesting it), while thedefault for the command line interface is chosen to try to ensurepipis available in most virtual environments without additional action on thepart of the end user.
As this change will only benefit Python 3.4 and later versions, thethird-partyvirtualenv project will still be needed to obtain aconsistent cross-version experience in Python 3.3 and 2.7.
The “Installing Python Modules” section of the standard librarydocumentation in Python 2.7, 3.3 and 3.4 will be updated to recommendthe use of thepip installer, either provided by default in Python 3.4or retrieved and installed by the user in Python 2.7 or 3.3. It will givea brief description of the most common commands and options, but delegateto the externally maintainedpip documentation for the full details.
In Python 3.4, thepyvenv andvenv documentation will also beupdated to reference the revised module installation guide.
The existing content of the module installation guide will be retained inall versions, but under a new “Invoking distutils directly” subsection.
Theensurepip implementation will include thepip CA bundle alongwith the rest ofpip. This means CPython effectively includesa CA bundle that is used solely bypip after it has been extracted.
This is considered preferable to relying solely on the systemcertificate stores, as it ensures thatpip will behave the sameacross all supported versions of Python, even those prior to Python 3.4that cannot access the system certificate store on Windows.
pip currently depends onsetuptools to handle metadata generationduring the build process, along with some other features. While work isongoing to reduce or eliminate this dependency, it is not clear if thatwork will be complete for pip 1.5 (which is the version likely to be currentwhen Python 3.4.0 is released).
This PEP proposes that, if pip still requires it as a dependency,ensurepip will include a private copy ofsetuptools (in additionto the private copy ofensurepip).python-mensurepip will theninstall the private copy in addition to installingpip itself.
However, this behavior is officially considered an implementationdetail. Other projects which explicitly requiresetuptools must stillprovide an appropriate dependency declaration, rather than assumingsetuptools will always be installed alongsidepip.
The private copy ofsetuptools will be removed fromensurepiponce it is no longer needed. This is likely to be at the point whenget-pip.py stops installingsetuptools by default.As long as setuptools is needed, it will be a completely unmodified copy ofthe latest upstream setuptools release, including theeasy_installscript if the upstream setuptools continues to include it. The installationofeasy_install along withpip isn’t considered desirable, butinstalling a broken setuptools would be worse. This problem willnaturally resolve itself once thepip developers have managed toeliminate their dependency onsetuptools and the private copy ofsetuptools can be removed entirely from CPython.
In order to keep up with evolutions in packaging as well as providing userswith as recent version a possible theensurepip module will beregularly updated to the latest versions of everything it bootstraps.
After each newpip release, and again during the preparation for anyrelease of Python (including feature releases), a script, provided as partof the implementation for this PEP, will be run to ensure the privatecopies stored in the CPython source repository have been updated to thelatest versions.
Likevenv andpyvenv, theensurepip module API and CLIwill be governed by the normal rules for the standard library: nonew features are permitted in maintenance releases.
However, the embedded components may be updated as noted above, sothe extractedpip may offer additional functionality in maintenancereleases.
No changes are proposed to the CPython uninstallation process by this PEP.The bootstrapped pip will be installed the same way as any other pipinstalled packages, and will be handled in the same way as any otherpost-install additions to the Python environment.
At least on Windows, that means the bootstrapped files will beleft behind after uninstallation, since those files won’t be associatedwith the Python MSI installer.
While the case can be made for the CPython installers clearing out thesedirectories automatically, changing that behaviour is considered outsidethe scope of this PEP.
While the Windows installer was updated in Python 3.3 to optionallymakepython available on the PATH, no such change was made toinclude the script installation directory returned bysysconfig.get_path("scripts").
Accordingly, in addition to adding the option to extract and installpipduring installation, this PEP proposes that the Windows installer inPython 3.4 and later be updated to also add the path returned bysysconfig.get_path("scripts") to the Windows PATH when the PATHmodification option is enabled during installation
Note that this change will only be available in Python 3.4 and later.
This means that, for Python 3.3, the most reliable way to invoke pip globallyon Windows (without tinkering manually with PATH) will still remainpy-mpip (orpy-3-mpip to select the Python 3 version if bothPython 2 and 3 are installed) rather than simply callingpip. Thisworks because Python 3.3 provides the Python Launcher forWindows (and the associatedpy command) by default.
For Python 2.7 and 3.2, the most reliable mechanism will be to install thePython Launcher for Windows using the standalone installer and then usepy-mpip as noted above.
Adding the scripts directory to the system PATH will mean thatpipworks reliably in the “only one Python installation on the system PATH”case, withpy-mpip,pipX, orpipX.Y needed only to select anon-default version in the parallel installation case (and outside a virtualenvironment). This change should also make thepyvenv command substantiallyeasier to invoke on Windows, along with all scripts installed bypip,easy_install and similar tools.
While the script invocations on recent versions of Python will run throughthe Python launcher for Windows, this shouldn’t cause any issues, as longas the Python files in the Scripts directory correctly specify a Python versionin their shebang line or have an adjacent Windows executable (aseasy_install andpip do).
A common source of Python installations are through downstream distributorssuch as the various Linux Distributions[3][4][5], OSXpackage managers[6][7][8], and commercial Pythonredistributors[9][10][11]. In order toprovide a consistent, user-friendly experience to all users of Pythonregardless of how they obtained Python this PEP recommends and asks thatdownstream distributors:
pip is either installed or isotherwise made readily available to end users.ensurepip bootstrap during installation,similar to the CPython installers.pip withoutit being installed. Systems that choose this option should ensure thattheensurepip module still installs pip directly when invoked insidea virtual environment, but may modify the module in the system Pythoninstallation to redirect to the platform provided mechanism wheninstallingpip globally.ensurepip module in Python 3.4 or later.ensurepip will be required for automatic installation of pip intovirtual environments by thevenv module.virtualenv package for which manydownstream distributors have already made exception to the common“debundling” policy.pip needs to be updated due to a securityissue, so does the private copy in theensurepip bootstrap modulepython-mensurepip--version orensurepip.version().python-mensurepip orensurepip.bootstrap().pipinstall--upgradepip in a global installation should not affectany already created virtual environments (but is permitted to affectfuture virtual environments, even though it will not do so when usingthe standard implementation ofensurepip).pipinstall--upgradepip in a virtual environment should not affectthe global installation.setup.py.In the event that a Python redistributor choosesnot to follow theserecommendations, we request that they explicitly document this fact andprovide their users with suitable guidance on translating upstreampipbased installation instructions into something appropriate for the platform.
Other Python implementations are also encouraged to follow these guidelineswhere applicable.
The maintainers of the bootstrapped software and the CPython core team willwork together in order to address the needs of both. The bootstrappedsoftware will still remain external to CPython and this PEP does notinclude CPython subsuming the development responsibilities or designdecisions of the bootstrapped software. This PEP aims to decrease theburden on end users wanting to use third-party packages and thedecisions inside it are pragmatic ones that represent the trust that thePython community has already placed in the Python Packaging Authority asthe authors and maintainers ofpip,setuptools, PyPI,virtualenvand other related projects.
The public API and CLI of theensurepip module itself will fall underthe typical backwards compatibility policy of Python for its standardlibrary. The externally developed software that this PEP bundles does not.
Most importantly, this means that the bootstrapped version of pip may gainnew features in CPython maintenance releases, and pip continues to operate onits own 6 month release cycle rather than CPython’s 18-24 month cycle.
Any security update that affects theensurepip module will be sharedprior to release with the Python Security Response Team(security@python.org). The PSRT will then decide if the reported issuewarrants a security release of CPython with an updated private copy ofpip.
pip is currently licensed as 1 Clause BSD, and it contains code takenfrom other projects. Additionally this PEP will include setuptools untilsuch time as pip no longer requires it. The licenses for these appear inthe 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. Additionallyit is unclear if a CA Bundle is copyrightable material and thus if it needsor can be licensed at all.
Earlier versions of this PEP proposed changing the name of the scriptinstallation directory on Windows from “Scripts” to “bin” in order toimprove the cross-platform consistency of the virtual environments createdbypyvenv.
However, Paul Moore determined that this change was likely backwardsincompatible with cross-version Windows installers created with previousversions of Python, so the change has been removed from this PEP[2].
Earlier versions of this PEP made the case that the challenges of gettingpip bootstrapped for new users posed a significant enough barrier toPython’s future growth that it justified addingensurepip as a newfeature in the upcoming Python 2.7 and 3.3 maintenance releases.
While the proposal to providepip with Python 3.4 was universallypopular, this part of the proposal was highly controversial and ultimatelyrejected by MvL as BDFL-Delegate.
Accordingly, the proposal to backportensurepip to Python 2.7 and 3.3has been removed from this PEP in favour of creating a Windows installerforpip and a possible future PEP suggesting creation of an aggregateinstaller for Python 2.7 that combines CPython 2.7,pip and the PythonLauncher for Windows.
Earlier versions of this PEP called the bootstrapping modulegetpip anddefaulted to downloading and installingpip from PyPI, with the privatecopy used only as a fallback option or when explicitly requested.
This resulted in several complex edge cases, along with difficulties indefining a clean API and CLI for the bootstrap module. It also significantlyaltered the default trust model for the binary installers published onpython.org, as end users would need to explicitlyopt-out of trustingthe security of the PyPI ecosystem (rather than opting in to it byexplicitly invokingpip following installation).
As a result, the PEP was simplified to the current design, where thebootstrappingalways uses the private copy ofpip. Contacting PyPIis now always an explicit separate step, with direct access to the fullpip interface.
Removing the implicit attempt to access PyPI also made it feasible toinvokeensurepip by default when installing from a custom source build.
PEP 439, the predecessor for this PEP, proposes its own solution. Itssolution involves shipping a fakepip command that when executed wouldimplicitly bootstrap and install pip if it does not already exist. This hasbeen rejected because it is too “magical”. It hides from the end user whenexactly the pip command will be installed or that it is being installed atall. It also does not provide any recommendations or considerations towardsdownstream packagers who wish to manage the globally installed pip throughthe mechanisms typical for their system.
The implicit bootstrap mechanism also ran into possible permissions issues,if a user inadvertently attempted to bootstrap pip without write access tothe appropriate installation directories.
Similar to this PEP is the proposal of just including pip in the standardlibrary. This would ensure that Python always includes pip and fixes all of theend user facing problems with not having pip present by default. This has beenrejected because we’ve learned, through the inclusion and history ofdistutils in the standard library, that losing the ability to update thepackaging tools independently can leave the tooling in a state of constantlimbo. Making it unable to ever reasonably evolve in a time frame that actuallyaffects users as any new features will not be available to the generalpopulation foryears.
Allowing the packaging tools to progress separately from the Python releaseand adoption schedules allows the improvements to be used byall membersof the Python community and not just those able to live on the bleeding edgeof Python releases.
There have also been issues in the past with the “dual maintenance” problemif a project continues to be maintained externally whilealso having afork maintained in the standard library. Since external maintenance ofpip will always be needed to support earlier Python versions, theproposed bootstrapping mechanism will becoming the explicit responsibilityof the CPython core developers (assisted by the pip developers), whilepip issues reported to the CPython tracker will be migrated to the pipissue tracker. There will no doubt still be some user confusion over whichtracker to use, but hopefully less than has been seen historically whenincluding complete public copies of third-party projects in the standardlibrary.
The approach described in this PEP also avoids some technical issuesrelated to handling CPython maintenance updates when pip has beenindependently updated to a more recent version. The proposed pip-basedbootstrapping mechanism handles that automatically, since pip and thesystem installer never get into a fight about who owns the pipinstallation (it is always managed through pip, either directly, orindirectly via theensurepip bootstrap module).
Finally, the separate bootstrapping step means it is also easy to avoidinstallingpip at all if end users so desire. This is often the caseif integrators are using system packages to handle installation ofcomponents written in multiple languages using a common set of tools.
Some consideration was given to bootstrapping pip into the per-usersite-packages directory by default. However, this behavior would besurprising (as it differs from the default behavior of pip itself)and is also not currently considered reliable (there are some edge caseswhich are not handled correctly when pip is installed into the usersite-packages directory rather than the system site-packages).
This document has been placed in the public domain.
Source:https://github.com/python/peps/blob/main/peps/pep-0453.rst
Last modified:2025-02-01 08:55:40 GMT