merge
This commit is contained in:
commit
366c8ce39f
|
@ -87,10 +87,8 @@ Release Schedule
|
||||||
3.2.4 schedule
|
3.2.4 schedule
|
||||||
--------------
|
--------------
|
||||||
|
|
||||||
- 3.2.4 beta 1: planned for Oct/Nov 2012
|
- 3.2.4 candidate 1: March 23, 2013
|
||||||
- 3.2.4 candidate 1: following two weeks after beta 1
|
- 3.2.4 final: April 6, 2013
|
||||||
- 3.2.4 final: following two weeks after candidate 1, if no further RC
|
|
||||||
are necessary
|
|
||||||
|
|
||||||
-- Only security releases after 3.2.4 --
|
-- Only security releases after 3.2.4 --
|
||||||
|
|
||||||
|
|
|
@ -70,10 +70,8 @@ Release Schedule
|
||||||
3.3.1 schedule
|
3.3.1 schedule
|
||||||
--------------
|
--------------
|
||||||
|
|
||||||
- 3.3.1 beta 1: planned for Oct/Nov 2012
|
- 3.3.1 candidate 1: March 23, 2013
|
||||||
- 3.3.1 candidate 1: following two weeks after beta 1
|
- 3.3.1 final: April 6, 2013
|
||||||
- 3.3.1 final: following two weeks after candidate 1, if no further RC
|
|
||||||
are necessary
|
|
||||||
|
|
||||||
|
|
||||||
Features for 3.3
|
Features for 3.3
|
||||||
|
|
|
@ -0,0 +1,199 @@
|
||||||
|
PEP: 439
|
||||||
|
Title: Inclusion of pip bootstrap in Python installation
|
||||||
|
Version: $Revision$
|
||||||
|
Last-Modified: $Date$
|
||||||
|
Author: Richard Jones <richard@python.org>
|
||||||
|
BDFL-Delegate: Nick Coghlan <ncoghlan@gmail.com>
|
||||||
|
Discussions-To: <distutils-sig@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:
|
Loading…
Reference in New Issue