diff --git a/pep-0439.txt b/pep-0439.txt new file mode 100644 index 000000000..a0ec5f1a3 --- /dev/null +++ b/pep-0439.txt @@ -0,0 +1,199 @@ +PEP: 439 +Title: Inclusion of pip bootstrap in Python installation +Version: $Revision$ +Last-Modified: $Date$ +Author: Richard Jones +BDFL-Delegate: Nick Coghlan +Discussions-To: +Status: Draft +Type: Standards Track +Created: 18-Mar-2013 +Python-Version: 3.4 +Post-History: 19-Mar-2013 + + +Abstract +======== + +This PEP proposes the inclusion of a pip boostrap executable in the +Python 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 implement any package +management or installation mechanisms beyond those provided by PEPs +427 ("The Wheel Binary Package Format 1.0") and TODO distlib PEP. + + +Rationale +========= + +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. + + +Proposal +======== + +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 +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 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 [1]_ 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 + called "pip". +2. The user will invoke a pip command, typically "pip install + ", 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 +". + +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 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 +bootstrapping process. + +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. + + +Implementation +============== + +TBD + + +Risks +===== + +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 +revocation. + + +References +========== + +.. [1] PEP 405, Python Virtual Environments + http://www.python.org/dev/peps/pep-0405/ + + +Acknowledgments +=============== + +Nick Coghlan for his thoughts on the proposal and dealing with the Red +Hat issue. + +Jannis Leidel and Carl Meyer for their thoughts. + + +Copyright +========= + +This document has been placed in the public domain. + + + +.. + Local Variables: + mode: indented-text + indent-tabs-mode: nil + sentence-end-double-space: t + fill-column: 70 + coding: utf-8 + End: