Title: Inclusion of pip bootstrap in Python installation
Author: Richard Jones <email@example.com>
BDFL-Delegate: Nick Coghlan <firstname.lastname@example.org>
Type: Standards Track
This PEP proposes the inclusion of a pip boostrap executable in the
Python installation to simplify the use of 3rd-party modules by Python
This PEP does not propose to include the pip implementation in the
Python standard library. Nor does it propose to implement any package
management or installation mechanisms beyond those provided by PEPs
427 ("The Wheel Binary Package Format 1.0") and TODO distlib PEP.
Currently the user story for installing 3rd-party Python modules is
not as simple as it could be. It requires that all 3rd-party modules
inform the user of how to install the installer, typically via a link
to the installer. That link may be out of date or the steps required
to perform the install of the installer may be enough of a roadblock
to prevent the user from further progress.
Large Python projects which emphasise a low barrier to entry have
shied away from depending on third party packages because of the
introduction of this potential stumbling block for new users.
With the inclusion of the package installer command in the standard
Python installation the barrier to installing additional software is
considerably reduced. It is hoped that this will therefore increase
the likelihood that Python projects will reuse third party software.
It is also hoped that this is reduces the number of proposals to
include more and more software in the Python standard library, and
therefore that more popular Python software is more easily upgradeable
beyond requiring Python installation upgrades.
Python install includes an executable called "pip" that attempts to
import pip machinery. If it can then the pip command proceeds as
normal. If it cannot it will bootstrap pip by downloading the pip
implementation wheel file. Once installed, the pip command proceeds
A boostrap is used in the place of a the full pip code so that we
don't have to bundle pip and also the install tool is upgradeable
outside of the regular Python upgrade timeframe and processes.
To avoid issues with sudo we will have the bootstrap default to
installing the pip implementation to the per-user site-packages
directory defined in PEP 370 and implemented in Python 2.6/3.0. Since
we avoid installing to the system Python we also avoid conflicting
with any other packaging system (on Linux systems, for example.) If
the user is inside a virtual environment _ then the pip
implementation will be installed into that virtual environment.
The bootstrapping process will proceed as follows:
1. The user system has Python (3.4+) installed. In the "scripts"
directory of the Python installation there is the bootstrap script
2. The user will invoke a pip command, typically "pip install
<package>", for example "pip install Django".
3. The boostrap script will attempt to import the pip implementation.
If this succeeds, the pip command is processed normally.
4. On failing to import the pip implementation the bootstrap notifies
the user that it is "upgrading pip" and contacts PyPI to obtain the
latest download wheel file (see PEP 427.)
5. Upon downloading the file it is installed using the distlib
installation machinery for wheel packages. Upon completing the
installation the user is notified that "pip has been upgraded."
TODO how is it verified?
6. The pip tool may now import the pip implementation and continues to
process the requested user command normally.
Users may be running in an environment which cannot access the public
Internet and are relying solely on a local package repository. They
would use the "-i" (Base URL of Python Package Index) argument to the
"pip install" command. This use case will be handled by:
1. Recognising the command-line arguments that specify alternative or
additional locations to discover packages and attempting to
download the package from those locations.
2. If the package is not found there then we attempt to donwload it
using the standard "https://pypi.python.org/pypi/simple/pip" index.
3. If that also fails, for any reason, we indicate to the user the
operation we were attempting, the reason for failure (if we know
it) and display further instructions for downloading and installing
the file manually.
Manual installation of the pip implementation will be supported
through the manual download of the wheel file and "pip install
<downloaded wheel file>".
This installation will not perform standard pip installation steps of
saving the file to a cache directory or updating any local database of
The download of the pip implementation install file should be
performed securely. The transport from pypi.python.org will be done
over HTTPS but the CA certificate check will most likely not be
performed. Therefore we will utilise the embedded signature support
in the wheel format to validate the downloaded file.
Beyond those arguments controlling index location and download
options, the "pip" boostrap command may support further standard pip
options for verbosity, quietness and logging.
The "--no-install" option to the "pip" command will not affect the
An additional new Python package will be proposed, "pypublish", which
will be a tool for publishing packages to PyPI. It would replace the
current "python setup.py register" and "python setup.py upload"
distutils commands. Again because of the measured Python release
cycle and extensive existing Python installations these commands are
difficult to bugfix and extend. Additionally it is desired that the
"register" and "upload" commands be able to be performed over HTTPS
with certificate validation. Since shipping CA certificate keychains
with Python is not really feasible (updating the keychain is quite
difficult to manage) it is desirable that those commands, and the
accompanying keychain, be made installable and upgradeable outside of
The Fedora variant of Linux has had a separate program called "pip" (a
Perl package installer) available for install for some time. The
current Python "pip" program is installed as "pip-python". It is
hoped that the Fedora community will resolve this issue by renaming
the Perl installer.
Currently pip depends upon setuptools functionality. It is intended
that before Python 3.4 is shipped that the required functionlity will
be present in Python's standard library as the distlib module, and
that pip would be modified to use that functionality when present.
TODO PEP reference for distlib
The key that is used to sign the pip implementation download might be
compromised and this PEP currently proposes no mechanism for key
..  PEP 405, Python Virtual Environments
Nick Coghlan for his thoughts on the proposal and dealing with the Red
Jannis Leidel and Carl Meyer for their thoughts.
This document has been placed in the public domain.