Author: Richard Jones <email@example.com>
+BDFL-Delegate: Nick Coghlan <firstname.lastname@example.org>
installation to simplify the use of 3rd-party modules by Python users.
This PEP does not propose to include the pip implementation in the Python
-standard library. Nor does it propose to include any package management or
-installation mechanisms beyond those specified in PEPs 470 and TODO distlib PEP.
+standard library. Nor does it propose to implement any package management or
+installation mechanisms beyond those provided by PEPs 470 ("The Wheel Binary
+Package Format 1.0") and TODO distlib PEP.
more popular Python software is more easily upgradeable beyond requiring
Python installation upgrades.
-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 Python itself.
-TODO pypublish... hmm... but pypub is taken
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 install. Once installed, the pip
-command proceeds as normal.
+will bootstrap pip by downloading the pip implementation wheel file.
+Once installed, the pip command proceeds as normal.
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 install 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
+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 (TODO PEP
+ref) then the pip implementation will be installed into that virtual
The bootstrapping process will proceed as follows:
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
+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 installed files.
+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
+Beyond those arguments controlling index location and download options, the
+"pip" boostrap command may support further standard pip options for verbosity,
+The "--no-install" option to the "pip" command will not affect the bootstrapping
+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 Python itself.
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
+program is installed as "pip-python". It is hoped that the Fedora will
resolve this issue by renaming the Perl installer.
-The download of the pip install wheel file cannot be fully secured. We can make
-an SSL (HTTPS) connection, but we cannot verify the PyPI certificate without a
-CA certificates keychain. As mentioned before, this will not be available in a
-Python installation due to the problems of managing the keychain. Any data
-transferred from PyPI, even over HTTPS, must therefore be considered vulnerable
-to Man-In-The-Middle (MITM) attack.
-One solution to the MITM attack could be to ship a public key matching the PyPI
-key with Python and validate just that against the PyPI server key. Any approach
-here must consider the response to the PyPI key being expired or replaced.
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
+that functionality when present. TODO PEP reference for distlib