This PEP proposes the inclusion of a pip bootstrap executable in thePython installation to simplify the use of 3rd-party modules by Pythonusers.
This PEP does not propose to include the pip implementation in thePython standard library. Nor does it propose to implement any packagemanagement or installation mechanisms beyond those provided by PEP427 (“The Wheel Binary Package Format 1.0”) and TODO distlib PEP.
This PEP has been rejected in favour of a more explicit mechanism thatshould achieve the same end result in a more reliable fashion. The moreexplicit bootstrapping mechanism is described inPEP 453.
Currently the user story for installing 3rd-party Python modules isnot as simple as it could be. It requires that all 3rd-party modulesinform the user of how to install the installer, typically via a linkto the installer. That link may be out of date or the steps requiredto perform the install of the installer may be enough of a roadblockto prevent the user from further progress.
Large Python projects which emphasise a low barrier to entry haveshied away from depending on third party packages because of theintroduction of this potential stumbling block for new users.
With the inclusion of the package installer command in the standardPython installation the barrier to installing additional software isconsiderably reduced. It is hoped that this will therefore increasethe likelihood that Python projects will reuse third party software.
The Python community also has an issue of complexity around the currentbootstrap procedure for pip and setuptools. They all havetheir own bootstrap download file with slightly different usages andeven refer to each other in some cases. Having a single bootstrap whichis common amongst them all, with a simple usage, would be far preferable.
It is also hoped that this is reduces the number of proposals toinclude more and more software in the Python standard library, andtherefore that more popular Python software is more easily upgradeablebeyond requiring Python installation upgrades.
The bootstrap will install the pip implementation, setuptools by downloadingtheir installation files from PyPI.
This proposal affects two components of packaging:the pip bootstrap and,thanks to easier package installation,modifications to publishingpackages.
The core of this proposal is that the user experience of using pip should notrequire the user to install pip.
The Python installation includes an executable called “pip3” (seePEP 394 fornaming rationale etc.) that attempts to import pip machinery. If it can thenthe pip command proceeds as normal. If it cannot it will bootstrap pip bydownloading the pip implementation and setuptools wheel files. Hereafter theinstallation of the “pip implementation” will imply installation of setuptoolsand virtualenv. Once installed, the pip command proceeds as normal. Once thebootstrap process is complete the “pip3” command is no longer the bootstrapbut rather the full pip command.
A bootstrap is used in the place of a the full pip code so that we don’t haveto bundle pip and also pip is upgradeable outside of the regular Pythonupgrade timeframe and processes.
To avoid issues with sudo we will have the bootstrap default toinstalling the pip implementation to the per-user site-packagesdirectory defined inPEP 370 and implemented in Python 2.6/3.0. Sincewe avoid installing to the system Python we also avoid conflictingwith any other packaging system (on Linux systems, for example.) Ifthe user is inside aPEP 405 virtual environment then the pipimplementation will be installed into that virtual environment.
The bootstrap process will proceed as follows:
Users may be running in an environment which cannot access the publicInternet and are relying solely on a local package repository. Theywould use the “-i” (Base URL of Python Package Index) argument to the“pip3 install” command. This simply overrides the default index URL pointingto PyPI.
Some users may have no Internet access suitable for fetching the pipimplementation file. These users can manually download and install thesetuptools and pip tar files. Adding specific support for this use-case isunnecessary.
The download of the pip implementation install file will be performedsecurely. The transport from pypi.python.org will be done over HTTPS with theCA certificate check performed. This facility will be present in Python 3.4+using Operating System certificates (see PEP XXXX).
Beyond those arguments controlling index location and downloadoptions, the “pip3” bootstrap command may support further standard pipoptions for verbosity, quietness and logging.
The “pip3” command will support two new command-line options that are usedin the bootstrapping, and otherwise ignored. They control where the pipimplementation is installed:
--bootstrap--bootstrap-to-systemThese command-line options will also need to be implemented, but otherwiseignored, in the pip implementation.
Consideration should be given to defaulting pip to install packages to theuser’s packages directory if pip is installed in that location.
The “–no-install” option to the “pip3” command will not affect thebootstrapping process.
An additional new Python package is proposed, “pypublish”, whichwill be a tool for publishing packages to PyPI. It would replace thecurrent “python setup.py register” and “python setup.py upload”distutils commands. Again because of the measured Python releasecycle and extensive existing Python installations these commands aredifficult to bugfix and extend. Additionally it is desired that the“register” and “upload” commands be able to be performed over HTTPSwith certificate validation. Since shipping CA certificate keychainswith Python is not really feasible (updating the keychain is quitedifficult to manage) it is desirable that those commands, and theaccompanying keychain, be made installable and upgradeable outside ofPython itself.
The existing distutils mechanisms for package registration and upload wouldremain, though with a deprecation warning.
The changes to pip required by this PEP are being tracked in that project’sissue tracker[2]. Most notably, the addition of –bootstrap and–bootstrap-to-system to the pip command-line.
It would be preferable that the pip and setuptools projects distribute a wheelformat download.
The required code for this implementation is the “pip3” command describedabove. The additional pypublish can be developed outside of the scope of thisPEP’s work.
Finally, it would be desirable that “pip3” be ported to Python 2.6+ to allowthe single command to replace existing pip, setuptools and virtualenv (whichwould be added to the bootstrap) bootstrap scripts. Having that bootstrapincluded in a future Python 2.7 release would also be highly desirable.
The key that is used to sign the pip implementation download might becompromised and this PEP currently proposes no mechanism for keyrevocation.
There is a Perl package installer also named “pip”. It is quite rare and notcommonly used. The Fedora variant of Linux has historically named Python’s“pip” as “python-pip” and Perl’s “pip” as “perl-pip”. This policy has beenaltered[3] so that future and upgraded Fedora installations will use the name“pip” for Python’s “pip”. Existing (non-upgraded) installations will stillhave the old name for the Python “pip”, though the potential for confusion isnow much reduced.
Alyssa Coghlan for her thoughts on the proposal and dealing with the RedHat issue.
Jannis Leidel and Carl Meyer for their thoughts. Marcus Smith for feedback.
Marcela Mašláňová for resolving the Fedora issue.
This document has been placed in the public domain.
Source:https://github.com/python/peps/blob/main/peps/pep-0439.rst
Last modified:2025-02-01 08:59:27 GMT