[Python-checkins] peps (merge default -> default): merge
richard.jones
python-checkins at python.org
Thu Mar 21 17:13:30 CET 2013
http://hg.python.org/peps/rev/be717b8c29e1
changeset: 4817:be717b8c29e1
parent: 4816:6605b658710c
parent: 4815:c4798da31ab0
user: Richard Jones <richard at mechanicalcat.net>
date: Thu Mar 21 09:13:23 2013 -0700
summary:
merge
files:
pep-0392.txt | 6 +-
pep-0398.txt | 6 +-
pep-0439.txt | 199 +++++++++++++++++++++++++++++++++++++++
3 files changed, 203 insertions(+), 8 deletions(-)
diff --git a/pep-0392.txt b/pep-0392.txt
--- a/pep-0392.txt
+++ b/pep-0392.txt
@@ -87,10 +87,8 @@
3.2.4 schedule
--------------
-- 3.2.4 beta 1: planned for Oct/Nov 2012
-- 3.2.4 candidate 1: following two weeks after beta 1
-- 3.2.4 final: following two weeks after candidate 1, if no further RC
- are necessary
+- 3.2.4 candidate 1: March 23, 2013
+- 3.2.4 final: April 6, 2013
-- Only security releases after 3.2.4 --
diff --git a/pep-0398.txt b/pep-0398.txt
--- a/pep-0398.txt
+++ b/pep-0398.txt
@@ -70,10 +70,8 @@
3.3.1 schedule
--------------
-- 3.3.1 beta 1: planned for Oct/Nov 2012
-- 3.3.1 candidate 1: following two weeks after beta 1
-- 3.3.1 final: following two weeks after candidate 1, if no further RC
- are necessary
+- 3.3.1 candidate 1: March 23, 2013
+- 3.3.1 final: April 6, 2013
Features for 3.3
diff --git a/pep-0439.txt b/pep-0439.txt
new file mode 100644
--- /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 <richard at python.org>
+BDFL-Delegate: Nick Coghlan <ncoghlan at gmail.com>
+Discussions-To: <distutils-sig at python.org>
+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
+ <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
+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:
--
Repository URL: http://hg.python.org/peps
More information about the Python-checkins
mailing list