iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
python-peps/pep-0453/index.html

1135 lines
93 KiB
HTML
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="color-scheme" content="light dark">
<title>PEP 453 – Explicit bootstrapping of pip in Python installations | peps.python.org</title>
<link rel="shortcut icon" href="../_static/py.png">
<link rel="canonical" href="https://peps.python.org/pep-0453/">
<link rel="stylesheet" href="../_static/style.css" type="text/css">
<link rel="stylesheet" href="../_static/mq.css" type="text/css">
<link rel="stylesheet" href="../_static/pygments.css" type="text/css" media="(prefers-color-scheme: light)" id="pyg-light">
<link rel="stylesheet" href="../_static/pygments_dark.css" type="text/css" media="(prefers-color-scheme: dark)" id="pyg-dark">
<link rel="alternate" type="application/rss+xml" title="Latest PEPs" href="https://peps.python.org/peps.rss">
<meta property="og:title" content='PEP 453 – Explicit bootstrapping of pip in Python installations | peps.python.org'>
<meta property="og:description" content="This PEP proposes that the Installing Python Modules guide in Python 2.7, 3.3 and 3.4 be updated to officially recommend the use of pip as the default installer for Python packages, and that appropriate technical changes be made in Python 3.4 to provide...">
<meta property="og:type" content="website">
<meta property="og:url" content="https://peps.python.org/pep-0453/">
<meta property="og:site_name" content="Python Enhancement Proposals (PEPs)">
<meta property="og:image" content="https://peps.python.org/_static/og-image.png">
<meta property="og:image:alt" content="Python PEPs">
<meta property="og:image:width" content="200">
<meta property="og:image:height" content="200">
<meta name="description" content="This PEP proposes that the Installing Python Modules guide in Python 2.7, 3.3 and 3.4 be updated to officially recommend the use of pip as the default installer for Python packages, and that appropriate technical changes be made in Python 3.4 to provide...">
<meta name="theme-color" content="#3776ab">
</head>
<body>
<svg xmlns="http://www.w3.org/2000/svg" style="display: none;">
<symbol id="svg-sun-half" viewBox="0 0 24 24" pointer-events="all">
<title>Following system colour scheme</title>
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none"
stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round">
<circle cx="12" cy="12" r="9"></circle>
<path d="M12 3v18m0-12l4.65-4.65M12 14.3l7.37-7.37M12 19.6l8.85-8.85"></path>
</svg>
</symbol>
<symbol id="svg-moon" viewBox="0 0 24 24" pointer-events="all">
<title>Selected dark colour scheme</title>
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none"
stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round">
<path stroke="none" d="M0 0h24v24H0z" fill="none"></path>
<path d="M12 3c.132 0 .263 0 .393 0a7.5 7.5 0 0 0 7.92 12.446a9 9 0 1 1 -8.313 -12.454z"></path>
</svg>
</symbol>
<symbol id="svg-sun" viewBox="0 0 24 24" pointer-events="all">
<title>Selected light colour scheme</title>
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none"
stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round">
<circle cx="12" cy="12" r="5"></circle>
<line x1="12" y1="1" x2="12" y2="3"></line>
<line x1="12" y1="21" x2="12" y2="23"></line>
<line x1="4.22" y1="4.22" x2="5.64" y2="5.64"></line>
<line x1="18.36" y1="18.36" x2="19.78" y2="19.78"></line>
<line x1="1" y1="12" x2="3" y2="12"></line>
<line x1="21" y1="12" x2="23" y2="12"></line>
<line x1="4.22" y1="19.78" x2="5.64" y2="18.36"></line>
<line x1="18.36" y1="5.64" x2="19.78" y2="4.22"></line>
</svg>
</symbol>
</svg>
<script>
document.documentElement.dataset.colour_scheme = localStorage.getItem("colour_scheme") || "auto"
</script>
<section id="pep-page-section">
<header>
<h1>Python Enhancement Proposals</h1>
<ul class="breadcrumbs">
<li><a href="https://www.python.org/" title="The Python Programming Language">Python</a> &raquo; </li>
<li><a href="../pep-0000/">PEP Index</a> &raquo; </li>
<li>PEP 453</li>
</ul>
<button id="colour-scheme-cycler" onClick="setColourScheme(nextColourScheme())">
<svg aria-hidden="true" class="colour-scheme-icon-when-auto"><use href="#svg-sun-half"></use></svg>
<svg aria-hidden="true" class="colour-scheme-icon-when-dark"><use href="#svg-moon"></use></svg>
<svg aria-hidden="true" class="colour-scheme-icon-when-light"><use href="#svg-sun"></use></svg>
<span class="visually-hidden">Toggle light / dark / auto colour theme</span>
</button>
</header>
<article>
<section id="pep-content">
<h1 class="page-title">PEP 453 – Explicit bootstrapping of pip in Python installations</h1>
<dl class="rfc2822 field-list simple">
<dt class="field-odd">Author<span class="colon">:</span></dt>
<dd class="field-odd">Donald Stufft &lt;donald&#32;&#97;t&#32;stufft.io&gt;,
Alyssa Coghlan &lt;ncoghlan&#32;&#97;t&#32;gmail.com&gt;</dd>
<dt class="field-even">BDFL-Delegate<span class="colon">:</span></dt>
<dd class="field-even">Martin von Löwis</dd>
<dt class="field-odd">Status<span class="colon">:</span></dt>
<dd class="field-odd"><abbr title="Accepted and implementation complete, or no longer active">Final</abbr></dd>
<dt class="field-even">Type<span class="colon">:</span></dt>
<dd class="field-even"><abbr title="Normative PEP with a new feature for Python, implementation change for CPython or interoperability standard for the ecosystem">Standards Track</abbr></dd>
<dt class="field-odd">Created<span class="colon">:</span></dt>
<dd class="field-odd">10-Aug-2013</dd>
<dt class="field-even">Post-History<span class="colon">:</span></dt>
<dd class="field-even">30-Aug-2013, 15-Sep-2013, 18-Sep-2013, 19-Sep-2013,
23-Sep-2013, 29-Sep-2013, 13-Oct-2013, 20-Oct-2013</dd>
<dt class="field-odd">Resolution<span class="colon">:</span></dt>
<dd class="field-odd"><a class="reference external" href="https://mail.python.org/pipermail/python-dev/2013-October/129810.html">Python-Dev message</a></dd>
</dl>
<hr class="docutils" />
<section id="contents">
<details><summary>Table of Contents</summary><ul class="simple">
<li><a class="reference internal" href="#abstract">Abstract</a></li>
<li><a class="reference internal" href="#pep-acceptance">PEP Acceptance</a></li>
<li><a class="reference internal" href="#rationale">Rationale</a><ul>
<li><a class="reference internal" href="#improving-the-new-user-experience">Improving the new user experience</a></li>
<li><a class="reference internal" href="#enabling-the-evolution-of-the-broader-python-packaging-ecosystem">Enabling the evolution of the broader Python packaging ecosystem</a></li>
<li><a class="reference internal" href="#why-pip">Why pip?</a></li>
</ul>
</li>
<li><a class="reference internal" href="#proposal-overview">Proposal Overview</a></li>
<li><a class="reference internal" href="#explicit-bootstrapping-mechanism">Explicit bootstrapping mechanism</a><ul>
<li><a class="reference internal" href="#security-considerations">Security considerations</a></li>
<li><a class="reference internal" href="#reliability-considerations">Reliability considerations</a></li>
<li><a class="reference internal" href="#implementation-strategy">Implementation strategy</a></li>
<li><a class="reference internal" href="#integration-timeline">Integration timeline</a></li>
<li><a class="reference internal" href="#proposed-cli">Proposed CLI</a></li>
<li><a class="reference internal" href="#proposed-module-api">Proposed module API</a></li>
<li><a class="reference internal" href="#invocation-from-the-cpython-installers">Invocation from the CPython installers</a></li>
<li><a class="reference internal" href="#installing-from-source">Installing from source</a></li>
<li><a class="reference internal" href="#changes-to-virtual-environments">Changes to virtual environments</a></li>
<li><a class="reference internal" href="#documentation">Documentation</a></li>
<li><a class="reference internal" href="#bundling-ca-certificates-with-cpython">Bundling CA certificates with CPython</a></li>
<li><a class="reference internal" href="#automatic-installation-of-setuptools">Automatic installation of setuptools</a></li>
<li><a class="reference internal" href="#updating-the-private-copy-of-pip">Updating the private copy of pip</a></li>
<li><a class="reference internal" href="#updating-the-ensurepip-module-api-and-cli">Updating the ensurepip module API and CLI</a></li>
</ul>
</li>
<li><a class="reference internal" href="#uninstallation">Uninstallation</a></li>
<li><a class="reference internal" href="#script-execution-on-windows">Script Execution on Windows</a></li>
<li><a class="reference internal" href="#recommendations-for-downstream-distributors">Recommendations for Downstream Distributors</a></li>
<li><a class="reference internal" href="#policies-governance">Policies &amp; Governance</a><ul>
<li><a class="reference internal" href="#backwards-compatibility">Backwards Compatibility</a></li>
<li><a class="reference internal" href="#security-releases">Security Releases</a></li>
<li><a class="reference internal" href="#licensing">Licensing</a></li>
</ul>
</li>
<li><a class="reference internal" href="#appendix-rejected-proposals">Appendix: Rejected Proposals</a><ul>
<li><a class="reference internal" href="#changing-the-name-of-the-scripts-directory-on-windows">Changing the name of the scripts directory on Windows</a></li>
<li><a class="reference internal" href="#including-ensurepip-in-python-2-7-and-3-3">Including ensurepip in Python 2.7, and 3.3</a></li>
<li><a class="reference internal" href="#automatically-contacting-pypi-when-bootstrapping-pip">Automatically contacting PyPI when bootstrapping pip</a></li>
<li><a class="reference internal" href="#implicit-bootstrap">Implicit bootstrap</a></li>
<li><a class="reference internal" href="#including-pip-directly-in-the-standard-library">Including pip directly in the standard library</a></li>
<li><a class="reference internal" href="#defaulting-to-user-installation">Defaulting to –user installation</a></li>
</ul>
</li>
<li><a class="reference internal" href="#references">References</a></li>
<li><a class="reference internal" href="#copyright">Copyright</a></li>
</ul>
</details></section>
<section id="abstract">
<h2><a class="toc-backref" href="#abstract" role="doc-backlink">Abstract</a></h2>
<p>This PEP proposes that the
<a class="reference external" href="http://docs.python.org/3/install">Installing Python Modules</a> guide in
Python 2.7, 3.3 and 3.4 be updated to officially recommend the use of <code class="docutils literal notranslate"><span class="pre">pip</span></code>
as the default installer for Python packages, and that appropriate technical
changes be made in Python 3.4 to provide <code class="docutils literal notranslate"><span class="pre">pip</span></code> by default in support of
that recommendation.</p>
</section>
<section id="pep-acceptance">
<h2><a class="toc-backref" href="#pep-acceptance" role="doc-backlink">PEP Acceptance</a></h2>
<p>This PEP was accepted for inclusion in Python 3.4 by Martin von Löwis on
Tuesday 22nd October, 2013.</p>
<p><a class="reference external" href="https://github.com/python/cpython/issues/63546">Issue 19347</a> has been created to
track the implementation of this PEP.</p>
</section>
<section id="rationale">
<h2><a class="toc-backref" href="#rationale" role="doc-backlink">Rationale</a></h2>
<p>There are two related, but distinct rationales for the proposal in this
PEP. The first relates to the experience of new users, while the second
relates to better enabling the evolution of the broader Python packaging
ecosystem.</p>
<section id="improving-the-new-user-experience">
<h3><a class="toc-backref" href="#improving-the-new-user-experience" role="doc-backlink">Improving the new user experience</a></h3>
<p>Currently, on systems without a platform package manager and repository,
installing a third-party Python package into a freshly installed Python
requires first identifying an appropriate package manager and then
installing it.</p>
<p>Even on systems that <em>do</em> have a platform package manager, it is unlikely to
include every package that is available on the Python Package Index, and
even when a desired third-party package is available, the correct name in
the platform package manager may not be clear.</p>
<p>This means that, to work effectively with the Python Package Index
ecosystem, users must know which package manager to install, where to get
it, and how to install it. The effect of this is that third-party Python
projects are currently required to choose from a variety of undesirable
alternatives:</p>
<ul class="simple">
<li>Assume the user already has a suitable cross-platform package manager
installed.</li>
<li>Duplicate the instructions and tell their users how to install the
package manager.</li>
<li>Completely forgo the use of dependencies to ease installation concerns
for their users.</li>
</ul>
<p>All of these available options have significant drawbacks.</p>
<p>If a project simply assumes a user already has the tooling then beginning
users may get a confusing error message when the installation command
doesn’t work. Some operating systems may ease this pain by providing a
global hook that looks for commands that don’t exist and suggest an OS
package they can install to make the command work, but that only works
on systems with platform package managers that include a package that
provides the relevant cross-platform installer command (such as many major
Linux distributions). No such assistance is available for Windows and
Mac OS X users, or more conservative Linux distributions. The challenges
of dealing with this problem for beginners (who are often also completely
new to programming, the use of command line tools and editing system
environment variables) are a regular feature of feedback the core Python
developers receive from professional educators and others introducing new
users to Python.</p>
<p>If a project chooses to duplicate the installation instructions and tell
their users how to install the package manager before telling them how to
install their own project then whenever these instructions need updates
they need updating by every project that has duplicated them. This is
particular problematic when there are multiple competing installation
tools available, and different projects recommend different tools.</p>
<p>This specific problem can be partially alleviated by strongly promoting
<code class="docutils literal notranslate"><span class="pre">pip</span></code> as the default installer and recommending that other projects
reference <a class="reference external" href="http://www.pip-installer.org/en/latest/installing.html">pip’s own bootstrapping instructions</a> rather than
duplicating them. However the user experience created by this approach
still isn’t particularly good (although there is an effort under way to
create a combined Windows installer for <code class="docutils literal notranslate"><span class="pre">pip</span></code> and its dependencies that
should improve matters on that platform, and Mac OS X and *nix platforms
generally have <code class="docutils literal notranslate"><span class="pre">wget</span></code> and hence the ability to easily download and run the
bootstrap scripts from the command line).</p>
<p>The projects that have decided to forgo dependencies altogether are forced
to either duplicate the efforts of other projects by inventing their own
solutions to problems or are required to simply include the other projects
in their own source trees. Both of these options present their own problems
either in duplicating maintenance work across the ecosystem or potentially
leaving users vulnerable to security issues because the included code or
duplicated efforts are not automatically updated when upstream releases a new
version.</p>
<p>By officially recommending and providing by default a specific cross-platform
package manager it will be easier for users trying to install these
third-party packages as well as easier for the people distributing them as
they should now be able to safely assume that most users will have the
appropriate installation tools available (or access to clear instructions on
how to obtain them). This is expected to become more important in the future
as the <a class="pep reference internal" href="../pep-0427/" title="PEP 427 – The Wheel Binary Package Format 1.0">Wheel</a> package format (deliberately) does not have a built in
“installer” in the form of <code class="docutils literal notranslate"><span class="pre">setup.py</span></code> so users wishing to install
from a wheel file will want an installer even in the simplest cases.</p>
<p>Reducing the burden of actually installing a third-party package should
also decrease the pressure to add every useful module to the standard
library. This will allow additions to the standard library to focus more
on why Python should have a particular tool out of the box, and why it
is reasonable for that package to adopt the standard library’s 18-24 month
feature release cycle, instead of using the general difficulty of installing
third-party packages as justification for inclusion.</p>
<p>Providing a standard installation system also helps with bootstrapping
alternate build and installer systems, such as <code class="docutils literal notranslate"><span class="pre">zc.buildout</span></code>, <code class="docutils literal notranslate"><span class="pre">hashdist</span></code>
and <code class="docutils literal notranslate"><span class="pre">conda</span></code>. So long as <code class="docutils literal notranslate"><span class="pre">pip</span> <span class="pre">install</span> <span class="pre">&lt;tool&gt;</span></code> works, then a standard
Python-specific installer provides a reasonably secure, cross platform
mechanism to get access to these utilities.</p>
</section>
<section id="enabling-the-evolution-of-the-broader-python-packaging-ecosystem">
<h3><a class="toc-backref" href="#enabling-the-evolution-of-the-broader-python-packaging-ecosystem" role="doc-backlink">Enabling the evolution of the broader Python packaging ecosystem</a></h3>
<p>As no new packaging standard can achieve widespread adoption without a
transition strategy that covers the versions of Python that are in
widespread <em>current</em> use (rather than merely future versions, like most
language features), the change proposed in this PEP is considered a
necessary step in the evolution of the Python packaging ecosystem</p>
<p>The broader community has embraced the Python Package Index as a mechanism
for distributing and installing Python software, but the different concerns
of language evolution and secure software distribution mean that a faster
feature release cycle that encompasses older versions is needed to properly
support the latter.</p>
<p>In addition, the core CPython development team have the luxury of
dropping support for earlier Python versions well before the rest of the
community, as downstream commercial redistributors pick up the task of
providing support for those versions to users that still need it, while
many third party libraries maintain compatibility with those versions as
long as they remain in widespread use.</p>
<p>This means that the current <code class="docutils literal notranslate"><span class="pre">setup.py</span> <span class="pre">install</span></code> based model for package
installation poses serious difficulties for the development and adoption
of new packaging standards, as, depending on how a project writes their
<code class="docutils literal notranslate"><span class="pre">setup.py</span></code> file, the installation command (along with other operations)
may end up invoking the standard library’s <code class="docutils literal notranslate"><span class="pre">distutils</span></code> package.</p>
<p>As an indicator of how this may cause problems for the broader ecosystem,
consider that the feature set of <code class="docutils literal notranslate"><span class="pre">distutils</span></code> in Python 2.6 was frozen
in June 2008 (with the release of Python 2.6b1), while the feature set of
<code class="docutils literal notranslate"><span class="pre">distutils</span></code> in Python 2.7 was frozen in April 2010 (with the release of
Python 2.7b1).</p>
<p>By contrast, using a separate installer application like <code class="docutils literal notranslate"><span class="pre">pip</span></code> (which
ensures that even <code class="docutils literal notranslate"><span class="pre">setup.py</span></code> files that invoke <code class="docutils literal notranslate"><span class="pre">distutils</span></code> directly
still support the new packaging standards) makes it possible to support
new packaging standards in older versions of Python, just by upgrading
<code class="docutils literal notranslate"><span class="pre">pip</span></code> (which receives new feature releases roughly every 6 months). The
situation on older versions of Python is further improved by making it
easier for end users to install and upgrade newer build systems like
<code class="docutils literal notranslate"><span class="pre">setuptools</span></code> or improved PyPI upload utilities like <code class="docutils literal notranslate"><span class="pre">twine</span></code>.</p>
<p>It is not coincidental that this proposed model of using a separate installer
program with more metadata heavy and less active distribution formats matches
that used by most operating systems (including Windows since the introduction
of the installer service and the MSI file format), as well as many other
language specific installers.</p>
<p>For Python 2.6, this compatibility issue is largely limited to various
enterprise Linux distributions (and their downstream derivatives). These
distributions often have even slower update cycles than CPython, so they
offer full support for versions of Python that are considered “security
fix only” versions upstream (and sometimes may even be to the point where
the core development team no longer support them at all - you can still get
commercial support for Python 2.3 if you really need it!).</p>
<p>In practice, the fact that tools like <code class="docutils literal notranslate"><span class="pre">wget</span></code> and <code class="docutils literal notranslate"><span class="pre">curl</span></code> are readily
available on Linux systems, that most users of Python on Linux are
already familiar with the command line, and that most Linux distributions
ship with a default configuration that makes running Python scripts easy,
means that the existing <code class="docutils literal notranslate"><span class="pre">pip</span></code> bootstrapping instructions for any *nix
system are already quite straightforward. Even if <code class="docutils literal notranslate"><span class="pre">pip</span></code> isn’t provided by
the system package manager, then using <code class="docutils literal notranslate"><span class="pre">wget</span></code> or <code class="docutils literal notranslate"><span class="pre">curl</span></code> to retrieve the
bootstrap script from www.pip-installer.org and then running it is just a
couple of shell commands that can easily be copied and pasted as necessary.</p>
<p>Accordingly, for any version of Python on any *nix system, the need to
bootstrap <code class="docutils literal notranslate"><span class="pre">pip</span></code> in older versions isn’t considered a major barrier to
adoption of new packaging standards, since it’s just one more small
speedbump encountered by users of these long term stable releases. For
*nix systems, this PEP’s formal endorsement of <code class="docutils literal notranslate"><span class="pre">pip</span></code> as the preferred
default packaging tool is seen as more important than the underlying
technical details involved in making <code class="docutils literal notranslate"><span class="pre">pip</span></code> available by default, since
it shifts the nature of the conversation between the developers of <code class="docutils literal notranslate"><span class="pre">pip</span></code>
and downstream repackagers of both <code class="docutils literal notranslate"><span class="pre">pip</span></code> and CPython.</p>
<p>For Python 2.7, on the other hand, the compatibility issue for adopting new
metadata standards is far more widespread, as it affects the python.org
binary installers for Windows and Mac OS X, as well as even relatively
fast moving *nix platforms.</p>
<p>Firstly, and unlike Python 2.6, Python 2.7 is still a fully supported
upstream version, and will remain so until the release of Python 2.7.9
(currently scheduled for May 2015), at which time it is expected to enter
the usual “security fix only” mode. That means there are at least another
19 months where Python 2.7 is a deployment target for Python applications
that enjoys full upstream support. Even after the core development team
switches 2.7 to security release only mode in 2015, Python 2.7 will likely
remain a commercially supported legacy target out beyond 2020.</p>
<p>While Python 3 already presents a compelling alternative over Python 2 for
<em>new</em> Python applications and deployments without an existing investment
in Python 2 and without a dependency on specific Python 2 only third party
modules (a set which is getting ever smaller over time), it is going to take
longer to create compelling business cases to update existing Python 2.7
based infrastructure to Python 3, especially in situations where the culture
of automated testing is weak (or nonexistent), making it difficult to
effectively use the available migration utilities.</p>
<p>While this PEP only proposes documentation changes for Python 2.7, once
<code class="docutils literal notranslate"><span class="pre">pip</span></code> has a Windows installer available, a separate PEP will be created
and submitted proposing the creation and distribution of aggregate installers
for future CPython 2.7 maintenance releases that combine the CPython,
<code class="docutils literal notranslate"><span class="pre">pip</span></code> and Python Launcher for Windows installers into a single download
(the separate downloads would still remain available - the aggregate
installers would be provided as a convenience, and as a clear indication
of the recommended operating environment for Python in Windows systems).</p>
</section>
<section id="why-pip">
<h3><a class="toc-backref" href="#why-pip" role="doc-backlink">Why pip?</a></h3>
<p><code class="docutils literal notranslate"><span class="pre">pip</span></code> has been chosen as the preferred default installer, as it is an
already popular tool that addresses several design and user experience
issues with its predecessor <code class="docutils literal notranslate"><span class="pre">easy_install</span></code> (these issues can’t readily
be fixed in <code class="docutils literal notranslate"><span class="pre">easy_install</span></code> itself due to backwards compatibility
concerns). <code class="docutils literal notranslate"><span class="pre">pip</span></code> is also well suited to working within the bounds of
a single Python runtime installation (including associated virtual
environments), which is a desirable feature for a tool bundled with CPython.</p>
<p>Other tools like <code class="docutils literal notranslate"><span class="pre">zc.buildout</span></code> and <code class="docutils literal notranslate"><span class="pre">conda</span></code> are more ambitious in their
aims (and hence substantially better than <code class="docutils literal notranslate"><span class="pre">pip</span></code> at handling external
binary dependencies), so it makes sense for the Python ecosystem to treat
them more like platform package managers to interoperate with rather than
as the default cross-platform installation tool. This relationship is
similar to that between <code class="docutils literal notranslate"><span class="pre">pip</span></code> and platform package management systems
like <code class="docutils literal notranslate"><span class="pre">apt</span></code> and <code class="docutils literal notranslate"><span class="pre">yum</span></code> (which are also designed to handle arbitrary
binary dependencies).</p>
</section>
</section>
<section id="proposal-overview">
<h2><a class="toc-backref" href="#proposal-overview" role="doc-backlink">Proposal Overview</a></h2>
<p>This PEP proposes that the
<a class="reference external" href="http://docs.python.org/3/install">Installing Python Modules</a> guide be
updated to officially recommend the use of <code class="docutils literal notranslate"><span class="pre">pip</span></code> as the default
installer for Python packages, rather than the current approach of
recommending the direct invocation of the <code class="docutils literal notranslate"><span class="pre">setup.py</span> <span class="pre">install</span></code> command.</p>
<p>However, to avoid recommending a tool that CPython does not provide, it is
further proposed that the <a class="reference external" href="http://www.pip-installer.org">pip</a> package manager be made available by
default when installing CPython 3.4 or later and when creating virtual
environments using the standard library’s <code class="docutils literal notranslate"><span class="pre">venv</span></code> module via the
<code class="docutils literal notranslate"><span class="pre">pyvenv</span></code> command line utility.</p>
<p>To support that end, this PEP proposes the inclusion of an <code class="docutils literal notranslate"><span class="pre">ensurepip</span></code>
bootstrapping module in Python 3.4, as well as automatic invocation of that
module from <code class="docutils literal notranslate"><span class="pre">pyvenv</span></code> and changes to the way Python installed scripts are
handled on Windows. Using a bootstrap module rather than providing <code class="docutils literal notranslate"><span class="pre">pip</span></code>
directly helps to clearly demarcate development responsibilities, and to
avoid inadvertently downgrading <code class="docutils literal notranslate"><span class="pre">pip</span></code> when updating CPython.</p>
<p>To provide clear guidance for new users of Python that may not be
starting with the latest release, this PEP also proposes that the
“Installing Python Modules” guides in Python 2.7 and 3.3 be updated to
recommend installing and using <code class="docutils literal notranslate"><span class="pre">pip</span></code>, rather than invoking <code class="docutils literal notranslate"><span class="pre">distutils</span></code>
directly. It does <em>not</em> propose backporting any of the code changes that
are being proposed for Python 3.4.</p>
<p>Finally, the PEP also strongly recommends that CPython redistributors and
other Python implementations ensure that <code class="docutils literal notranslate"><span class="pre">pip</span></code> is available by default, or
at the very least, explicitly document the fact that it is not included.</p>
<p>This PEP does <em>not</em> propose making pip (or any dependencies) directly
available as part of the standard library. Instead, pip will be a
bundled application provided along with CPython for the convenience
of Python users, but subject to its own development life cycle and able
to be upgraded independently of the core interpreter and standard library.</p>
</section>
<section id="explicit-bootstrapping-mechanism">
<h2><a class="toc-backref" href="#explicit-bootstrapping-mechanism" role="doc-backlink">Explicit bootstrapping mechanism</a></h2>
<p>An additional module called <code class="docutils literal notranslate"><span class="pre">ensurepip</span></code> will be added to the standard
library whose purpose is to install pip and any of its dependencies into the
appropriate location (most commonly site-packages). It will expose a
callable named <code class="docutils literal notranslate"><span class="pre">bootstrap()</span></code> as well as offer direct execution via
<code class="docutils literal notranslate"><span class="pre">python</span> <span class="pre">-m</span> <span class="pre">ensurepip</span></code>.</p>
<p>The bootstrap will <em>not</em> contact PyPI, but instead rely on a private copy
of pip stored inside the standard library. Accordingly, only options
related to the installation location will be supported (<code class="docutils literal notranslate"><span class="pre">--user</span></code>,
<code class="docutils literal notranslate"><span class="pre">--root</span></code>, etc).</p>
<p>It is considered desirable that users be strongly encouraged to use the
latest available version of <code class="docutils literal notranslate"><span class="pre">pip</span></code>, in order to take advantage of the
ongoing efforts to improve the security of the PyPI based ecosystem, as
well as benefiting from the efforts to improve the speed, reliability and
flexibility of that ecosystem.</p>
<p>In order to satisfy this goal of providing the most recent version of
<code class="docutils literal notranslate"><span class="pre">pip</span></code> by default, the private copy of <code class="docutils literal notranslate"><span class="pre">pip</span></code> will be updated in CPython
maintenance releases, which should align well with the 6-month cycle used
for new <code class="docutils literal notranslate"><span class="pre">pip</span></code> releases.</p>
<section id="security-considerations">
<h3><a class="toc-backref" href="#security-considerations" role="doc-backlink">Security considerations</a></h3>
<p>The design in this PEP has been deliberately chosen to avoid making any
significant changes to the trust model of CPython for end users that do
not subsequently run the command <code class="docutils literal notranslate"><span class="pre">pip</span> <span class="pre">install</span> <span class="pre">--upgrade</span> <span class="pre">pip</span></code>.</p>
<p>The installers will contain all the components of a fully functioning
version of Python, including the <code class="docutils literal notranslate"><span class="pre">pip</span></code> installer. The installation
process will <em>not</em> require network access, and will <em>not</em> rely on
trusting the security of the network connection established between
<code class="docutils literal notranslate"><span class="pre">pip</span></code> and the Python package index.</p>
<p>Only users that choose to use <code class="docutils literal notranslate"><span class="pre">pip</span></code> to communicate with PyPI will
need to pay attention to the additional security considerations that come
with doing so.</p>
<p>However, the core CPython team will still assist with reviewing and
resolving at least the <a class="reference external" href="https://github.com/kennethreitz/requests/issues/1659">certificate update management issue</a> currently
affecting the <code class="docutils literal notranslate"><span class="pre">requests</span></code> project (and hence <code class="docutils literal notranslate"><span class="pre">pip</span></code>), and may also be
able to offer assistance in resolving other identified security concerns
<a class="footnote-reference brackets" href="#cert-verification" id="id1">[1]</a>.</p>
</section>
<section id="reliability-considerations">
<h3><a class="toc-backref" href="#reliability-considerations" role="doc-backlink">Reliability considerations</a></h3>
<p>By including the bootstrap as part of the standard library (rather than
solely as a feature of the binary installers), the correct operation of
the bootstrap command can be easily tested using the existing CPython
buildbot infrastructure rather than adding significantly to the testing
burden for the installers themselves.</p>
</section>
<section id="implementation-strategy">
<h3><a class="toc-backref" href="#implementation-strategy" role="doc-backlink">Implementation strategy</a></h3>
<p>To ensure there is no need for network access when installing Python or
creating virtual environments, the <code class="docutils literal notranslate"><span class="pre">ensurepip</span></code> module will, as an
implementation detail, include a complete private copy of pip and its
dependencies which will be used to extract pip and install it into the target
environment. It is important to stress that this private copy of pip is
<em>only</em> an implementation detail and it should <em>not</em> be relied on or
assumed to exist beyond the public capabilities exposed through the
<code class="docutils literal notranslate"><span class="pre">ensurepip</span></code> module (and indirectly through <code class="docutils literal notranslate"><span class="pre">venv</span></code>).</p>
<p>There is not yet a reference <code class="docutils literal notranslate"><span class="pre">ensurepip</span></code> implementation. The existing
<code class="docutils literal notranslate"><span class="pre">get-pip.py</span></code> bootstrap script demonstrates an earlier variation of the
general concept, but the standard library version would take advantage of
the improved distribution capabilities offered by the CPython installers
to include private copies of <code class="docutils literal notranslate"><span class="pre">pip</span></code> and <code class="docutils literal notranslate"><span class="pre">setuptools</span></code> as wheel files
(rather than as embedded base64 encoded data), and would not try to
contact PyPI (instead installing directly from the private wheel files).</p>
<p>Rather than including separate code to handle the bootstrapping, the
<code class="docutils literal notranslate"><span class="pre">ensurepip</span></code> module will manipulate <code class="docutils literal notranslate"><span class="pre">sys.path</span></code> appropriately to allow
the wheel files to be used to install themselves, either into the current
Python installation or into a virtual environment (as determined by the
options passed to the bootstrap command).</p>
<p>It is proposed that the implementation be carried out in five separate
steps (all steps after the first two are independent of each other and
can be carried out in any order):</p>
<ul class="simple">
<li>the first step would update the “Installing Python Modules” documentation
to recommend the use of <code class="docutils literal notranslate"><span class="pre">pip</span></code> and reference the <code class="docutils literal notranslate"><span class="pre">pip</span></code> team’s
instructions for downloading and installing it. This change would be
applied to Python 2.7, 3.3, and 3.4.</li>
<li>the <code class="docutils literal notranslate"><span class="pre">ensurepip</span></code> module and the private copies of the most recently
released versions of pip and setuptools would be added to Python 3.4
and the 3.4 “Installing Python Modules” documentation updated accordingly.</li>
<li>the CPython Windows installer would be updated to offer the new <code class="docutils literal notranslate"><span class="pre">pip</span></code>
installation option for Python 3.4.</li>
<li>the CPython Mac OS X installer would be updated to offer the new <code class="docutils literal notranslate"><span class="pre">pip</span></code>
installation option for Python 3.4.</li>
<li>the <code class="docutils literal notranslate"><span class="pre">venv</span></code> module and <code class="docutils literal notranslate"><span class="pre">pyvenv</span></code> command would be updated to make use
of <code class="docutils literal notranslate"><span class="pre">ensurepip</span></code> in Python 3.4</li>
<li>the PATH handling on Windows would be updated for Python 3.4+</li>
</ul>
</section>
<section id="integration-timeline">
<h3><a class="toc-backref" href="#integration-timeline" role="doc-backlink">Integration timeline</a></h3>
<p>If this PEP is accepted, the proposed time frame for integration of <code class="docutils literal notranslate"><span class="pre">pip</span></code>
into the CPython release is as follows:</p>
<ul class="simple">
<li>as soon as possible after the release of 3.4.0 alpha 4<ul>
<li>Documentation updated and <code class="docutils literal notranslate"><span class="pre">ensurepip</span></code> implemented based on a
pre-release version of <code class="docutils literal notranslate"><span class="pre">pip</span></code> 1.5.</li>
<li>All other proposed functional changes for Python 3.4 implemented,
including the installer updates to invoke <code class="docutils literal notranslate"><span class="pre">ensurepip</span></code>.</li>
</ul>
</li>
<li>by November 20th (3 days prior to the scheduled date of 3.4.0 beta 1)<ul>
<li><code class="docutils literal notranslate"><span class="pre">ensurepip</span></code> updated to use a <code class="docutils literal notranslate"><span class="pre">pip</span></code> 1.5 release candidate.</li>
<li><a class="pep reference internal" href="../pep-0101/" title="PEP 101 – Doing Python Releases 101">PEP 101</a> updated to cover ensuring the bundled version of <code class="docutils literal notranslate"><span class="pre">pip</span></code> is up
to date.</li>
</ul>
</li>
<li>by November 24th (scheduled date of 3.4.0 beta 1)<ul>
<li>As with any other new feature, all proposed functional changes for
Python 3.4 must be implemented prior to the beta feature freeze.</li>
</ul>
</li>
<li>by December 29th (1 week prior to the scheduled date of 3.4.0 beta 2)<ul>
<li><code class="docutils literal notranslate"><span class="pre">requests</span></code> certificate management issue resolved</li>
<li><code class="docutils literal notranslate"><span class="pre">ensurepip</span></code> updated to the final release of <code class="docutils literal notranslate"><span class="pre">pip</span></code> 1.5, or a
subsequent maintenance release (including a suitably updated vendored
copy of <code class="docutils literal notranslate"><span class="pre">requests</span></code>)</li>
</ul>
</li>
</ul>
<p>(See <a class="pep reference internal" href="../pep-0429/" title="PEP 429 – Python 3.4 Release Schedule">PEP 429</a> for the current official scheduled dates of each release. Dates
listed above are accurate as of October 20th, 2013.)</p>
<p>If there is no final or maintenance release of <code class="docutils literal notranslate"><span class="pre">pip</span></code> 1.5 with a suitable
updated version of <code class="docutils literal notranslate"><span class="pre">requests</span></code> available by one week before the scheduled
Python 3.4 beta 2 release, then implementation of this PEP will
be deferred to Python 3.5. Note that this scenario is considered unlikely -
the tentative date for the <code class="docutils literal notranslate"><span class="pre">pip</span></code> 1.5 release is currently December 1st.</p>
<p>In future CPython releases, this kind of coordinated scheduling shouldn’t be
needed: the CPython release manager will be able to just update to the latest
released version of <code class="docutils literal notranslate"><span class="pre">pip</span></code>. However, in this case, some fixes are needed in
<code class="docutils literal notranslate"><span class="pre">pip</span></code> in order to allow the bundling to work correctly, and the
certificate update mechanism for <code class="docutils literal notranslate"><span class="pre">requests</span></code> needs to be improved, so the
<code class="docutils literal notranslate"><span class="pre">pip</span></code> 1.5 release cycle needs to be properly aligned with the CPython 3.4
beta releases.</p>
</section>
<section id="proposed-cli">
<h3><a class="toc-backref" href="#proposed-cli" role="doc-backlink">Proposed CLI</a></h3>
<p>The proposed CLI is based on a subset of the existing <code class="docutils literal notranslate"><span class="pre">pip</span> <span class="pre">install</span></code>
options:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">Usage</span><span class="p">:</span>
<span class="n">python</span> <span class="o">-</span><span class="n">m</span> <span class="n">ensurepip</span> <span class="p">[</span><span class="n">options</span><span class="p">]</span>
<span class="n">General</span> <span class="n">Options</span><span class="p">:</span>
<span class="o">-</span><span class="n">h</span><span class="p">,</span> <span class="o">--</span><span class="n">help</span> <span class="n">Show</span> <span class="n">help</span><span class="o">.</span>
<span class="o">-</span><span class="n">v</span><span class="p">,</span> <span class="o">--</span><span class="n">verbose</span> <span class="n">Give</span> <span class="n">more</span> <span class="n">output</span><span class="o">.</span> <span class="n">Option</span> <span class="ow">is</span> <span class="n">additive</span><span class="p">,</span> <span class="ow">and</span> <span class="n">can</span> <span class="n">be</span> <span class="n">used</span> <span class="n">up</span> <span class="n">to</span> <span class="mi">3</span> <span class="n">times</span><span class="o">.</span>
<span class="o">-</span><span class="n">V</span><span class="p">,</span> <span class="o">--</span><span class="n">version</span> <span class="n">Show</span> <span class="n">the</span> <span class="n">pip</span> <span class="n">version</span> <span class="n">that</span> <span class="n">would</span> <span class="n">be</span> <span class="n">extracted</span> <span class="ow">and</span> <span class="n">exit</span><span class="o">.</span>
<span class="o">-</span><span class="n">q</span><span class="p">,</span> <span class="o">--</span><span class="n">quiet</span> <span class="n">Give</span> <span class="n">less</span> <span class="n">output</span><span class="o">.</span>
<span class="n">Installation</span> <span class="n">Options</span><span class="p">:</span>
<span class="o">-</span><span class="n">U</span><span class="p">,</span> <span class="o">--</span><span class="n">upgrade</span> <span class="n">Upgrade</span> <span class="n">pip</span> <span class="ow">and</span> <span class="n">dependencies</span><span class="p">,</span> <span class="n">even</span> <span class="k">if</span> <span class="n">already</span> <span class="n">installed</span>
<span class="o">--</span><span class="n">user</span> <span class="n">Install</span> <span class="n">using</span> <span class="n">the</span> <span class="n">user</span> <span class="n">scheme</span><span class="o">.</span>
<span class="o">--</span><span class="n">root</span> <span class="o">&lt;</span><span class="nb">dir</span><span class="o">&gt;</span> <span class="n">Install</span> <span class="n">everything</span> <span class="n">relative</span> <span class="n">to</span> <span class="n">this</span> <span class="n">alternate</span> <span class="n">root</span> <span class="n">directory</span><span class="o">.</span>
</pre></div>
</div>
<p>In most cases, end users won’t need to use this CLI directly, as <code class="docutils literal notranslate"><span class="pre">pip</span></code>
should have been installed automatically when installing Python or when
creating a virtual environment. However, it is formally documented as a
public interface to support at least these known use cases:</p>
<ul class="simple">
<li>Windows and Mac OS X installations where the “Install pip” option was
<em>not</em> chosen during installation</li>
<li>any installation where the user previously ran “pip uninstall pip”</li>
</ul>
<p>Users that want to retrieve the latest version from PyPI, or otherwise
need more flexibility, can then invoke the extracted <code class="docutils literal notranslate"><span class="pre">pip</span></code> appropriately.</p>
</section>
<section id="proposed-module-api">
<h3><a class="toc-backref" href="#proposed-module-api" role="doc-backlink">Proposed module API</a></h3>
<p>The proposed <code class="docutils literal notranslate"><span class="pre">ensurepip</span></code> module API consists of the following two
functions:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="k">def</span> <span class="nf">version</span><span class="p">():</span>
<span class="w"> </span><span class="sd">&quot;&quot;&quot;</span>
<span class="sd"> Returns a string specifying the bundled version of pip.</span>
<span class="sd"> &quot;&quot;&quot;</span>
<span class="k">def</span> <span class="nf">bootstrap</span><span class="p">(</span><span class="n">root</span><span class="o">=</span><span class="kc">None</span><span class="p">,</span> <span class="n">upgrade</span><span class="o">=</span><span class="kc">False</span><span class="p">,</span> <span class="n">user</span><span class="o">=</span><span class="kc">False</span><span class="p">,</span> <span class="n">verbosity</span><span class="o">=</span><span class="mi">0</span><span class="p">):</span>
<span class="w"> </span><span class="sd">&quot;&quot;&quot;</span>
<span class="sd"> Bootstrap pip into the current Python installation (or the given root</span>
<span class="sd"> directory).</span>
<span class="sd"> &quot;&quot;&quot;</span>
</pre></div>
</div>
</section>
<section id="invocation-from-the-cpython-installers">
<h3><a class="toc-backref" href="#invocation-from-the-cpython-installers" role="doc-backlink">Invocation from the CPython installers</a></h3>
<p>The CPython Windows and Mac OS X installers will each gain a new option:</p>
<ul class="simple">
<li>Install pip (the default Python package management utility)?</li>
</ul>
<p>This option will be checked by default.</p>
<p>If the option is checked, then the installer will invoke the following
command with the just installed Python:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">python</span> <span class="o">-</span><span class="n">m</span> <span class="n">ensurepip</span> <span class="o">--</span><span class="n">upgrade</span>
</pre></div>
</div>
<p>This ensures that, by default, installing or updating CPython will ensure
that the installed version of pip is at least as recent as the one included
with that version of CPython. If a newer version of pip has already been
installed then <code class="docutils literal notranslate"><span class="pre">python</span> <span class="pre">-m</span> <span class="pre">ensurepip</span> <span class="pre">--upgrade</span></code> will simply return without
doing anything.</p>
</section>
<section id="installing-from-source">
<h3><a class="toc-backref" href="#installing-from-source" role="doc-backlink">Installing from source</a></h3>
<p>Just as the prebuilt binary installers will be updated to run
<code class="docutils literal notranslate"><span class="pre">python</span> <span class="pre">-m</span> <span class="pre">ensurepip</span></code> by default, a similar change will be made to the
<code class="docutils literal notranslate"><span class="pre">make</span> <span class="pre">install</span></code> and <code class="docutils literal notranslate"><span class="pre">make</span> <span class="pre">altinstall</span></code> commands of the source
distribution. The directory settings in the <code class="docutils literal notranslate"><span class="pre">sysconfig</span></code> module should
ensure the <code class="docutils literal notranslate"><span class="pre">pip</span></code> components are automatically installed to the expected
locations.</p>
<p><code class="docutils literal notranslate"><span class="pre">ensurepip</span></code> itself (including the private copy of <code class="docutils literal notranslate"><span class="pre">pip</span></code> and its
dependencies) will always be installed normally (as it is a regular
part of the standard library), but an option will be provided to skip
the invocation of <code class="docutils literal notranslate"><span class="pre">ensurepip</span></code>.</p>
<p>This means that even installing from source will provide <code class="docutils literal notranslate"><span class="pre">pip</span></code> by default,
but redistributors provide <code class="docutils literal notranslate"><span class="pre">pip</span></code> by other means (or not providing it at
all) will still be able to opt out of installing it using <code class="docutils literal notranslate"><span class="pre">ensurepip</span></code>.</p>
</section>
<section id="changes-to-virtual-environments">
<h3><a class="toc-backref" href="#changes-to-virtual-environments" role="doc-backlink">Changes to virtual environments</a></h3>
<p>Python 3.3 included a standard library approach to virtual Python environments
through the <code class="docutils literal notranslate"><span class="pre">venv</span></code> module. Since its release it has become clear that very
few users have been willing to use this feature directly, in part due to the
lack of an installer present by default inside of the virtual environment.
They have instead opted to continue using the <code class="docutils literal notranslate"><span class="pre">virtualenv</span></code> package which
<em>does</em> include pip installed by default.</p>
<p>To make the <code class="docutils literal notranslate"><span class="pre">venv</span></code> more useful to users it will be modified to issue the
pip bootstrap by default inside of the new environment while creating it. This
will allow people the same convenience inside of the virtual environment as
this PEP provides outside of it as well as bringing the <code class="docutils literal notranslate"><span class="pre">venv</span></code> module closer
to feature parity with the external <code class="docutils literal notranslate"><span class="pre">virtualenv</span></code> package, making it a more
suitable replacement.</p>
<p>To handle cases where a user does not wish to have pip bootstrapped into
their virtual environment a <code class="docutils literal notranslate"><span class="pre">--without-pip</span></code> option will be
added.</p>
<p>The <code class="docutils literal notranslate"><span class="pre">venv.EnvBuilder</span></code> and <code class="docutils literal notranslate"><span class="pre">venv.create</span></code> APIs will be updated to accept
one new parameter: <code class="docutils literal notranslate"><span class="pre">with_pip</span></code> (defaulting to <code class="docutils literal notranslate"><span class="pre">False</span></code>).</p>
<p>The new default for the module API is chosen for backwards compatibility
with the current behaviour (as it is assumed that most invocation of the
<code class="docutils literal notranslate"><span class="pre">venv</span></code> module happens through third part tools that likely will not
want <code class="docutils literal notranslate"><span class="pre">pip</span></code> installed without explicitly requesting it), while the
default for the command line interface is chosen to try to ensure <code class="docutils literal notranslate"><span class="pre">pip</span></code>
is available in most virtual environments without additional action on the
part of the end user.</p>
<p>As this change will only benefit Python 3.4 and later versions, the
third-party <code class="docutils literal notranslate"><span class="pre">virtualenv</span></code> project will still be needed to obtain a
consistent cross-version experience in Python 3.3 and 2.7.</p>
</section>
<section id="documentation">
<h3><a class="toc-backref" href="#documentation" role="doc-backlink">Documentation</a></h3>
<p>The “Installing Python Modules” section of the standard library
documentation in Python 2.7, 3.3 and 3.4 will be updated to recommend
the use of the <code class="docutils literal notranslate"><span class="pre">pip</span></code> installer, either provided by default in Python 3.4
or retrieved and installed by the user in Python 2.7 or 3.3. It will give
a brief description of the most common commands and options, but delegate
to the externally maintained <code class="docutils literal notranslate"><span class="pre">pip</span></code> documentation for the full details.</p>
<p>In Python 3.4, the <code class="docutils literal notranslate"><span class="pre">pyvenv</span></code> and <code class="docutils literal notranslate"><span class="pre">venv</span></code> documentation will also be
updated to reference the revised module installation guide.</p>
<p>The existing content of the module installation guide will be retained in
all versions, but under a new “Invoking distutils directly” subsection.</p>
</section>
<section id="bundling-ca-certificates-with-cpython">
<h3><a class="toc-backref" href="#bundling-ca-certificates-with-cpython" role="doc-backlink">Bundling CA certificates with CPython</a></h3>
<p>The <code class="docutils literal notranslate"><span class="pre">ensurepip</span></code> implementation will include the <code class="docutils literal notranslate"><span class="pre">pip</span></code> CA bundle along
with the rest of <code class="docutils literal notranslate"><span class="pre">pip</span></code>. This means CPython effectively includes
a CA bundle that is used solely by <code class="docutils literal notranslate"><span class="pre">pip</span></code> after it has been extracted.</p>
<p>This is considered preferable to relying solely on the system
certificate stores, as it ensures that <code class="docutils literal notranslate"><span class="pre">pip</span></code> will behave the same
across all supported versions of Python, even those prior to Python 3.4
that cannot access the system certificate store on Windows.</p>
</section>
<section id="automatic-installation-of-setuptools">
<h3><a class="toc-backref" href="#automatic-installation-of-setuptools" role="doc-backlink">Automatic installation of setuptools</a></h3>
<p><code class="docutils literal notranslate"><span class="pre">pip</span></code> currently depends on <code class="docutils literal notranslate"><span class="pre">setuptools</span></code> to handle metadata generation
during the build process, along with some other features. While work is
ongoing to reduce or eliminate this dependency, it is not clear if that
work will be complete for pip 1.5 (which is the version likely to be current
when Python 3.4.0 is released).</p>
<p>This PEP proposes that, if pip still requires it as a dependency,
<code class="docutils literal notranslate"><span class="pre">ensurepip</span></code> will include a private copy of <code class="docutils literal notranslate"><span class="pre">setuptools</span></code> (in addition
to the private copy of <code class="docutils literal notranslate"><span class="pre">ensurepip</span></code>). <code class="docutils literal notranslate"><span class="pre">python</span> <span class="pre">-m</span> <span class="pre">ensurepip</span></code> will then
install the private copy in addition to installing <code class="docutils literal notranslate"><span class="pre">pip</span></code> itself.</p>
<p>However, this behavior is officially considered an implementation
detail. Other projects which explicitly require <code class="docutils literal notranslate"><span class="pre">setuptools</span></code> must still
provide an appropriate dependency declaration, rather than assuming
<code class="docutils literal notranslate"><span class="pre">setuptools</span></code> will always be installed alongside <code class="docutils literal notranslate"><span class="pre">pip</span></code>.</p>
<p>The private copy of <code class="docutils literal notranslate"><span class="pre">setuptools</span></code> will be removed from <code class="docutils literal notranslate"><span class="pre">ensurepip</span></code>
once it is no longer needed. This is likely to be at the point when
<code class="docutils literal notranslate"><span class="pre">get-pip.py</span></code> stops installing <code class="docutils literal notranslate"><span class="pre">setuptools</span></code> by default.
As long as setuptools is needed, it will be a completely unmodified copy of
the latest upstream setuptools release, including the <code class="docutils literal notranslate"><span class="pre">easy_install</span></code>
script if the upstream setuptools continues to include it. The installation
of <code class="docutils literal notranslate"><span class="pre">easy_install</span></code> along with <code class="docutils literal notranslate"><span class="pre">pip</span></code> isn’t considered desirable, but
installing a broken setuptools would be worse. This problem will
naturally resolve itself once the <code class="docutils literal notranslate"><span class="pre">pip</span></code> developers have managed to
eliminate their dependency on <code class="docutils literal notranslate"><span class="pre">setuptools</span></code> and the private copy of
<code class="docutils literal notranslate"><span class="pre">setuptools</span></code> can be removed entirely from CPython.</p>
</section>
<section id="updating-the-private-copy-of-pip">
<h3><a class="toc-backref" href="#updating-the-private-copy-of-pip" role="doc-backlink">Updating the private copy of pip</a></h3>
<p>In order to keep up with evolutions in packaging as well as providing users
with as recent version a possible the <code class="docutils literal notranslate"><span class="pre">ensurepip</span></code> module will be
regularly updated to the latest versions of everything it bootstraps.</p>
<p>After each new <code class="docutils literal notranslate"><span class="pre">pip</span></code> release, and again during the preparation for any
release of Python (including feature releases), a script, provided as part
of the implementation for this PEP, will be run to ensure the private
copies stored in the CPython source repository have been updated to the
latest versions.</p>
</section>
<section id="updating-the-ensurepip-module-api-and-cli">
<h3><a class="toc-backref" href="#updating-the-ensurepip-module-api-and-cli" role="doc-backlink">Updating the ensurepip module API and CLI</a></h3>
<p>Like <code class="docutils literal notranslate"><span class="pre">venv</span></code> and <code class="docutils literal notranslate"><span class="pre">pyvenv</span></code>, the <code class="docutils literal notranslate"><span class="pre">ensurepip</span></code> module API and CLI
will be governed by the normal rules for the standard library: no
new features are permitted in maintenance releases.</p>
<p>However, the embedded components may be updated as noted above, so
the extracted <code class="docutils literal notranslate"><span class="pre">pip</span></code> may offer additional functionality in maintenance
releases.</p>
</section>
</section>
<section id="uninstallation">
<h2><a class="toc-backref" href="#uninstallation" role="doc-backlink">Uninstallation</a></h2>
<p>No changes are proposed to the CPython uninstallation process by this PEP.
The bootstrapped pip will be installed the same way as any other pip
installed packages, and will be handled in the same way as any other
post-install additions to the Python environment.</p>
<p>At least on Windows, that means the bootstrapped files will be
left behind after uninstallation, since those files won’t be associated
with the Python MSI installer.</p>
<p>While the case can be made for the CPython installers clearing out these
directories automatically, changing that behaviour is considered outside
the scope of this PEP.</p>
</section>
<section id="script-execution-on-windows">
<h2><a class="toc-backref" href="#script-execution-on-windows" role="doc-backlink">Script Execution on Windows</a></h2>
<p>While the Windows installer was updated in Python 3.3 to optionally
make <code class="docutils literal notranslate"><span class="pre">python</span></code> available on the PATH, no such change was made to
include the script installation directory returned by
<code class="docutils literal notranslate"><span class="pre">sysconfig.get_path(&quot;scripts&quot;)</span></code>.</p>
<p>Accordingly, in addition to adding the option to extract and install <code class="docutils literal notranslate"><span class="pre">pip</span></code>
during installation, this PEP proposes that the Windows installer in
Python 3.4 and later be updated to also add the path returned by
<code class="docutils literal notranslate"><span class="pre">sysconfig.get_path(&quot;scripts&quot;)</span></code> to the Windows PATH when the PATH
modification option is enabled during installation</p>
<p>Note that this change will only be available in Python 3.4 and later.</p>
<p>This means that, for Python 3.3, the most reliable way to invoke pip globally
on Windows (without tinkering manually with PATH) will still remain
<code class="docutils literal notranslate"><span class="pre">py</span> <span class="pre">-m</span> <span class="pre">pip</span></code> (or <code class="docutils literal notranslate"><span class="pre">py</span> <span class="pre">-3</span> <span class="pre">-m</span> <span class="pre">pip</span></code> to select the Python 3 version if both
Python 2 and 3 are installed) rather than simply calling <code class="docutils literal notranslate"><span class="pre">pip</span></code>. This
works because Python 3.3 provides the Python Launcher for
Windows (and the associated <code class="docutils literal notranslate"><span class="pre">py</span></code> command) by default.</p>
<p>For Python 2.7 and 3.2, the most reliable mechanism will be to install the
Python Launcher for Windows using the standalone installer and then use
<code class="docutils literal notranslate"><span class="pre">py</span> <span class="pre">-m</span> <span class="pre">pip</span></code> as noted above.</p>
<p>Adding the scripts directory to the system PATH will mean that <code class="docutils literal notranslate"><span class="pre">pip</span></code>
works reliably in the “only one Python installation on the system PATH”
case, with <code class="docutils literal notranslate"><span class="pre">py</span> <span class="pre">-m</span> <span class="pre">pip</span></code>, <code class="docutils literal notranslate"><span class="pre">pipX</span></code>, or <code class="docutils literal notranslate"><span class="pre">pipX.Y</span></code> needed only to select a
non-default version in the parallel installation case (and outside a virtual
environment). This change should also make the <code class="docutils literal notranslate"><span class="pre">pyvenv</span></code> command substantially
easier to invoke on Windows, along with all scripts installed by <code class="docutils literal notranslate"><span class="pre">pip</span></code>,
<code class="docutils literal notranslate"><span class="pre">easy_install</span></code> and similar tools.</p>
<p>While the script invocations on recent versions of Python will run through
the Python launcher for Windows, this shouldn’t cause any issues, as long
as the Python files in the Scripts directory correctly specify a Python version
in their shebang line or have an adjacent Windows executable (as
<code class="docutils literal notranslate"><span class="pre">easy_install</span></code> and <code class="docutils literal notranslate"><span class="pre">pip</span></code> do).</p>
</section>
<section id="recommendations-for-downstream-distributors">
<h2><a class="toc-backref" href="#recommendations-for-downstream-distributors" role="doc-backlink">Recommendations for Downstream Distributors</a></h2>
<p>A common source of Python installations are through downstream distributors
such as the various Linux Distributions <a class="footnote-reference brackets" href="#ubuntu" id="id2">[3]</a> <a class="footnote-reference brackets" href="#debian" id="id3">[4]</a> <a class="footnote-reference brackets" href="#fedora" id="id4">[5]</a>, OSX
package managers <a class="footnote-reference brackets" href="#homebrew" id="id5">[6]</a> <a class="footnote-reference brackets" href="#macports" id="id6">[7]</a> <a class="footnote-reference brackets" href="#fink" id="id7">[8]</a>, and commercial Python
redistributors <a class="footnote-reference brackets" href="#continuumio" id="id8">[9]</a> <a class="footnote-reference brackets" href="#activestate" id="id9">[10]</a> <a class="footnote-reference brackets" href="#enthought" id="id10">[11]</a>. In order to
provide a consistent, user-friendly experience to all users of Python
regardless of how they obtained Python this PEP recommends and asks that
downstream distributors:</p>
<ul class="simple">
<li>Ensure that whenever Python is installed <code class="docutils literal notranslate"><span class="pre">pip</span></code> is either installed or is
otherwise made readily available to end users.<ul>
<li>For redistributors using binary installers, this may take the form of
optionally executing the <code class="docutils literal notranslate"><span class="pre">ensurepip</span></code> bootstrap during installation,
similar to the CPython installers.</li>
<li>For redistributors using package management systems, it may take the
form of separate packages with dependencies on each other so that
installing the Python package installs the pip package and installing
the pip package installs the Python package.</li>
<li>Another reasonable way to implement this is to package pip separately but
ensure that there is some sort of global hook that will recommend
installing the separate pip package when a user executes <code class="docutils literal notranslate"><span class="pre">pip</span></code> without
it being installed. Systems that choose this option should ensure that
the <code class="docutils literal notranslate"><span class="pre">ensurepip</span></code> module still installs pip directly when invoked inside
a virtual environment, but may modify the module in the system Python
installation to redirect to the platform provided mechanism when
installing <code class="docutils literal notranslate"><span class="pre">pip</span></code> globally.</li>
</ul>
</li>
<li>Even if pip is made available globally by other means, do not remove the
<code class="docutils literal notranslate"><span class="pre">ensurepip</span></code> module in Python 3.4 or later.<ul>
<li><code class="docutils literal notranslate"><span class="pre">ensurepip</span></code> will be required for automatic installation of pip into
virtual environments by the <code class="docutils literal notranslate"><span class="pre">venv</span></code> module.</li>
<li>This is similar to the existing <code class="docutils literal notranslate"><span class="pre">virtualenv</span></code> package for which many
downstream distributors have already made exception to the common
“debundling” policy.</li>
<li>This does mean that if <code class="docutils literal notranslate"><span class="pre">pip</span></code> needs to be updated due to a security
issue, so does the private copy in the <code class="docutils literal notranslate"><span class="pre">ensurepip</span></code> bootstrap module</li>
<li>However, altering the private copy of pip to remove the embedded
CA certificate bundle and rely on the system CA bundle instead is a
reasonable change.</li>
</ul>
</li>
<li>Ensure that all features of this PEP continue to work with any modifications
made to the redistributed version of Python.<ul>
<li>Checking the version of pip that will be bootstrapped using
<code class="docutils literal notranslate"><span class="pre">python</span> <span class="pre">-m</span> <span class="pre">ensurepip</span> <span class="pre">--version</span></code> or <code class="docutils literal notranslate"><span class="pre">ensurepip.version()</span></code>.</li>
<li>Installation of pip into a global or virtual python environment using
<code class="docutils literal notranslate"><span class="pre">python</span> <span class="pre">-m</span> <span class="pre">ensurepip</span></code> or <code class="docutils literal notranslate"><span class="pre">ensurepip.bootstrap()</span></code>.</li>
<li><code class="docutils literal notranslate"><span class="pre">pip</span> <span class="pre">install</span> <span class="pre">--upgrade</span> <span class="pre">pip</span></code> in a global installation should not affect
any already created virtual environments (but is permitted to affect
future virtual environments, even though it will not do so when using
the standard implementation of <code class="docutils literal notranslate"><span class="pre">ensurepip</span></code>).</li>
<li><code class="docutils literal notranslate"><span class="pre">pip</span> <span class="pre">install</span> <span class="pre">--upgrade</span> <span class="pre">pip</span></code> in a virtual environment should not affect
the global installation.</li>
</ul>
</li>
<li>Migrate build systems to utilize <a class="reference external" href="http://www.pip-installer.org">pip</a> and <a class="pep reference internal" href="../pep-0427/" title="PEP 427 – The Wheel Binary Package Format 1.0">Wheel</a>
wherever feasible
and avoid directly invoking <code class="docutils literal notranslate"><span class="pre">setup.py</span></code>.<ul>
<li>This will help ensure a smoother and more timely migration to improved
metadata formats as the Python packaging ecosystem continues to evolve.</li>
</ul>
</li>
</ul>
<p>In the event that a Python redistributor chooses <em>not</em> to follow these
recommendations, we request that they explicitly document this fact and
provide their users with suitable guidance on translating upstream <code class="docutils literal notranslate"><span class="pre">pip</span></code>
based installation instructions into something appropriate for the platform.</p>
<p>Other Python implementations are also encouraged to follow these guidelines
where applicable.</p>
</section>
<section id="policies-governance">
<h2><a class="toc-backref" href="#policies-governance" role="doc-backlink">Policies &amp; Governance</a></h2>
<p>The maintainers of the bootstrapped software and the CPython core team will
work together in order to address the needs of both. The bootstrapped
software will still remain external to CPython and this PEP does not
include CPython subsuming the development responsibilities or design
decisions of the bootstrapped software. This PEP aims to decrease the
burden on end users wanting to use third-party packages and the
decisions inside it are pragmatic ones that represent the trust that the
Python community has already placed in the Python Packaging Authority as
the authors and maintainers of <code class="docutils literal notranslate"><span class="pre">pip</span></code>, <code class="docutils literal notranslate"><span class="pre">setuptools</span></code>, PyPI, <code class="docutils literal notranslate"><span class="pre">virtualenv</span></code>
and other related projects.</p>
<section id="backwards-compatibility">
<h3><a class="toc-backref" href="#backwards-compatibility" role="doc-backlink">Backwards Compatibility</a></h3>
<p>The public API and CLI of the <code class="docutils literal notranslate"><span class="pre">ensurepip</span></code> module itself will fall under
the typical backwards compatibility policy of Python for its standard
library. The externally developed software that this PEP bundles does not.</p>
<p>Most importantly, this means that the bootstrapped version of pip may gain
new features in CPython maintenance releases, and pip continues to operate on
its own 6 month release cycle rather than CPython’s 18-24 month cycle.</p>
</section>
<section id="security-releases">
<h3><a class="toc-backref" href="#security-releases" role="doc-backlink">Security Releases</a></h3>
<p>Any security update that affects the <code class="docutils literal notranslate"><span class="pre">ensurepip</span></code> module will be shared
prior to release with the Python Security Response Team
(<a class="reference external" href="mailto:security&#37;&#52;&#48;python&#46;org">security<span>&#64;</span>python<span>&#46;</span>org</a>). The PSRT will then decide if the reported issue
warrants a security release of CPython with an updated private copy of
<code class="docutils literal notranslate"><span class="pre">pip</span></code>.</p>
</section>
<section id="licensing">
<h3><a class="toc-backref" href="#licensing" role="doc-backlink">Licensing</a></h3>
<p><code class="docutils literal notranslate"><span class="pre">pip</span></code> is currently licensed as 1 Clause BSD, and it contains code taken
from other projects. Additionally this PEP will include setuptools until
such time as pip no longer requires it. The licenses for these appear in
the table below.</p>
<table class="docutils align-default">
<thead>
<tr class="row-odd"><th class="head">Project</th>
<th class="head">License</th>
</tr>
</thead>
<tbody>
<tr class="row-even"><td>requests</td>
<td>Apache 2.0</td>
</tr>
<tr class="row-odd"><td>six</td>
<td>1 Clause BSD</td>
</tr>
<tr class="row-even"><td>html5lib</td>
<td>1 Clause BSD</td>
</tr>
<tr class="row-odd"><td>distlib</td>
<td>PSF</td>
</tr>
<tr class="row-even"><td>colorama</td>
<td>3 Clause BSD</td>
</tr>
<tr class="row-odd"><td>Mozilla CA Bundle</td>
<td>LGPL</td>
</tr>
<tr class="row-even"><td>setuptools</td>
<td>PSF</td>
</tr>
</tbody>
</table>
<p>All of these licenses should be compatible with the PSF license. Additionally
it is unclear if a CA Bundle is copyrightable material and thus if it needs
or can be licensed at all.</p>
</section>
</section>
<section id="appendix-rejected-proposals">
<h2><a class="toc-backref" href="#appendix-rejected-proposals" role="doc-backlink">Appendix: Rejected Proposals</a></h2>
<section id="changing-the-name-of-the-scripts-directory-on-windows">
<h3><a class="toc-backref" href="#changing-the-name-of-the-scripts-directory-on-windows" role="doc-backlink">Changing the name of the scripts directory on Windows</a></h3>
<p>Earlier versions of this PEP proposed changing the name of the script
installation directory on Windows from “Scripts” to “bin” in order to
improve the cross-platform consistency of the virtual environments created
by <code class="docutils literal notranslate"><span class="pre">pyvenv</span></code>.</p>
<p>However, Paul Moore determined that this change was likely backwards
incompatible with cross-version Windows installers created with previous
versions of Python, so the change has been removed from this PEP
<a class="footnote-reference brackets" href="#windows-incompatibility" id="id11">[2]</a>.</p>
</section>
<section id="including-ensurepip-in-python-2-7-and-3-3">
<h3><a class="toc-backref" href="#including-ensurepip-in-python-2-7-and-3-3" role="doc-backlink">Including ensurepip in Python 2.7, and 3.3</a></h3>
<p>Earlier versions of this PEP made the case that the challenges of getting
<code class="docutils literal notranslate"><span class="pre">pip</span></code> bootstrapped for new users posed a significant enough barrier to
Python’s future growth that it justified adding <code class="docutils literal notranslate"><span class="pre">ensurepip</span></code> as a new
feature in the upcoming Python 2.7 and 3.3 maintenance releases.</p>
<p>While the proposal to provide <code class="docutils literal notranslate"><span class="pre">pip</span></code> with Python 3.4 was universally
popular, this part of the proposal was highly controversial and ultimately
<a class="reference external" href="https://mail.python.org/pipermail/python-dev/2013-September/129091.html">rejected by MvL as BDFL-Delegate</a>.</p>
<p>Accordingly, the proposal to backport <code class="docutils literal notranslate"><span class="pre">ensurepip</span></code> to Python 2.7 and 3.3
has been removed from this PEP in favour of creating a Windows installer
for <code class="docutils literal notranslate"><span class="pre">pip</span></code> and a possible future PEP suggesting creation of an aggregate
installer for Python 2.7 that combines CPython 2.7, <code class="docutils literal notranslate"><span class="pre">pip</span></code> and the Python
Launcher for Windows.</p>
</section>
<section id="automatically-contacting-pypi-when-bootstrapping-pip">
<h3><a class="toc-backref" href="#automatically-contacting-pypi-when-bootstrapping-pip" role="doc-backlink">Automatically contacting PyPI when bootstrapping pip</a></h3>
<p>Earlier versions of this PEP called the bootstrapping module <code class="docutils literal notranslate"><span class="pre">getpip</span></code> and
defaulted to downloading and installing <code class="docutils literal notranslate"><span class="pre">pip</span></code> from PyPI, with the private
copy used only as a fallback option or when explicitly requested.</p>
<p>This resulted in several complex edge cases, along with difficulties in
defining a clean API and CLI for the bootstrap module. It also significantly
altered the default trust model for the binary installers published on
python.org, as end users would need to explicitly <em>opt-out</em> of trusting
the security of the PyPI ecosystem (rather than opting in to it by
explicitly invoking <code class="docutils literal notranslate"><span class="pre">pip</span></code> following installation).</p>
<p>As a result, the PEP was simplified to the current design, where the
bootstrapping <em>always</em> uses the private copy of <code class="docutils literal notranslate"><span class="pre">pip</span></code>. Contacting PyPI
is now always an explicit separate step, with direct access to the full
pip interface.</p>
<p>Removing the implicit attempt to access PyPI also made it feasible to
invoke <code class="docutils literal notranslate"><span class="pre">ensurepip</span></code> by default when installing from a custom source build.</p>
</section>
<section id="implicit-bootstrap">
<h3><a class="toc-backref" href="#implicit-bootstrap" role="doc-backlink">Implicit bootstrap</a></h3>
<p><a class="pep reference internal" href="../pep-0439/" title="PEP 439 – Inclusion of implicit pip bootstrap in Python installation">PEP 439</a>, the predecessor for this PEP, proposes its own solution. Its
solution involves shipping a fake <code class="docutils literal notranslate"><span class="pre">pip</span></code> command that when executed would
implicitly bootstrap and install pip if it does not already exist. This has
been rejected because it is too “magical”. It hides from the end user when
exactly the pip command will be installed or that it is being installed at
all. It also does not provide any recommendations or considerations towards
downstream packagers who wish to manage the globally installed pip through
the mechanisms typical for their system.</p>
<p>The implicit bootstrap mechanism also ran into possible permissions issues,
if a user inadvertently attempted to bootstrap pip without write access to
the appropriate installation directories.</p>
</section>
<section id="including-pip-directly-in-the-standard-library">
<h3><a class="toc-backref" href="#including-pip-directly-in-the-standard-library" role="doc-backlink">Including pip directly in the standard library</a></h3>
<p>Similar to this PEP is the proposal of just including pip in the standard
library. This would ensure that Python always includes pip and fixes all of the
end user facing problems with not having pip present by default. This has been
rejected because we’ve learned, through the inclusion and history of
<code class="docutils literal notranslate"><span class="pre">distutils</span></code> in the standard library, that losing the ability to update the
packaging tools independently can leave the tooling in a state of constant
limbo. Making it unable to ever reasonably evolve in a time frame that actually
affects users as any new features will not be available to the general
population for <em>years</em>.</p>
<p>Allowing the packaging tools to progress separately from the Python release
and adoption schedules allows the improvements to be used by <em>all</em> members
of the Python community and not just those able to live on the bleeding edge
of Python releases.</p>
<p>There have also been issues in the past with the “dual maintenance” problem
if a project continues to be maintained externally while <em>also</em> having a
fork maintained in the standard library. Since external maintenance of
<code class="docutils literal notranslate"><span class="pre">pip</span></code> will always be needed to support earlier Python versions, the
proposed bootstrapping mechanism will becoming the explicit responsibility
of the CPython core developers (assisted by the pip developers), while
pip issues reported to the CPython tracker will be migrated to the pip
issue tracker. There will no doubt still be some user confusion over which
tracker to use, but hopefully less than has been seen historically when
including complete public copies of third-party projects in the standard
library.</p>
<p>The approach described in this PEP also avoids some technical issues
related to handling CPython maintenance updates when pip has been
independently updated to a more recent version. The proposed pip-based
bootstrapping mechanism handles that automatically, since pip and the
system installer never get into a fight about who owns the pip
installation (it is always managed through pip, either directly, or
indirectly via the <code class="docutils literal notranslate"><span class="pre">ensurepip</span></code> bootstrap module).</p>
<p>Finally, the separate bootstrapping step means it is also easy to avoid
installing <code class="docutils literal notranslate"><span class="pre">pip</span></code> at all if end users so desire. This is often the case
if integrators are using system packages to handle installation of
components written in multiple languages using a common set of tools.</p>
</section>
<section id="defaulting-to-user-installation">
<h3><a class="toc-backref" href="#defaulting-to-user-installation" role="doc-backlink">Defaulting to –user installation</a></h3>
<p>Some consideration was given to bootstrapping pip into the per-user
site-packages directory by default. However, this behavior would be
surprising (as it differs from the default behavior of pip itself)
and is also not currently considered reliable (there are some edge cases
which are not handled correctly when pip is installed into the user
site-packages directory rather than the system site-packages).</p>
</section>
</section>
<section id="references">
<h2><a class="toc-backref" href="#references" role="doc-backlink">References</a></h2>
<ul class="simple">
<li><a class="reference external" href="https://mail.python.org/pipermail/distutils-sig/2013-August/022529.html">Discussion thread 1 (distutils-sig)</a></li>
<li><a class="reference external" href="https://mail.python.org/pipermail/distutils-sig/2013-September/022702.html">Discussion thread 2 (distutils-sig)</a></li>
<li><a class="reference external" href="https://mail.python.org/pipermail/python-dev/2013-September/128723.html">Discussion thread 3 (python-dev)</a></li>
<li><a class="reference external" href="https://mail.python.org/pipermail/python-dev/2013-September/128780.html">Discussion thread 4 (python-dev)</a></li>
<li><a class="reference external" href="https://mail.python.org/pipermail/python-dev/2013-September/128894.html">Discussion thread 5 (python-dev)</a></li>
</ul>
<aside class="footnote-list brackets">
<aside class="footnote brackets" id="cert-verification" role="doc-footnote">
<dt class="label" id="cert-verification">[<a href="#id1">1</a>]</dt>
<dd><a class="reference external" href="https://mail.python.org/pipermail/python-dev/2013-October/129755.html">pip/requests certificate management concerns</a></aside>
<aside class="footnote brackets" id="windows-incompatibility" role="doc-footnote">
<dt class="label" id="windows-incompatibility">[<a href="#id11">2</a>]</dt>
<dd><a class="reference external" href="https://mail.python.org/pipermail/distutils-sig/2013-October/022855.html">Windows installer compatibility concerns</a></aside>
<aside class="footnote brackets" id="ubuntu" role="doc-footnote">
<dt class="label" id="ubuntu">[<a href="#id2">3</a>]</dt>
<dd><a class="reference external" href="http://www.ubuntu.com/">Ubuntu</a></aside>
<aside class="footnote brackets" id="debian" role="doc-footnote">
<dt class="label" id="debian">[<a href="#id3">4</a>]</dt>
<dd><a class="reference external" href="http://www.debian.org">Debian</a></aside>
<aside class="footnote brackets" id="fedora" role="doc-footnote">
<dt class="label" id="fedora">[<a href="#id4">5</a>]</dt>
<dd><a class="reference external" href="https://fedoraproject.org/">Fedora</a></aside>
<aside class="footnote brackets" id="homebrew" role="doc-footnote">
<dt class="label" id="homebrew">[<a href="#id5">6</a>]</dt>
<dd><a class="reference external" href="https://brew.sh/">Homebrew</a></aside>
<aside class="footnote brackets" id="macports" role="doc-footnote">
<dt class="label" id="macports">[<a href="#id6">7</a>]</dt>
<dd><a class="reference external" href="https://macports.org">MacPorts</a></aside>
<aside class="footnote brackets" id="fink" role="doc-footnote">
<dt class="label" id="fink">[<a href="#id7">8</a>]</dt>
<dd><a class="reference external" href="https://finkproject.org">Fink</a></aside>
<aside class="footnote brackets" id="continuumio" role="doc-footnote">
<dt class="label" id="continuumio">[<a href="#id8">9</a>]</dt>
<dd><a class="reference external" href="https://www.anaconda.com/products/distribution">Anaconda</a></aside>
<aside class="footnote brackets" id="activestate" role="doc-footnote">
<dt class="label" id="activestate">[<a href="#id9">10</a>]</dt>
<dd><a class="reference external" href="http://www.activestate.com/activepython">ActivePython</a></aside>
<aside class="footnote brackets" id="enthought" role="doc-footnote">
<dt class="label" id="enthought">[<a href="#id10">11</a>]</dt>
<dd><a class="reference external" href="https://www.enthought.com/products/canopy/">Enthought Canopy</a></aside>
</aside>
</section>
<section id="copyright">
<h2><a class="toc-backref" href="#copyright" role="doc-backlink">Copyright</a></h2>
<p>This document has been placed in the public domain.</p>
</section>
</section>
<hr class="docutils" />
<p>Source: <a class="reference external" href="https://github.com/python/peps/blob/main/peps/pep-0453.rst">https://github.com/python/peps/blob/main/peps/pep-0453.rst</a></p>
<p>Last modified: <a class="reference external" href="https://github.com/python/peps/commits/main/peps/pep-0453.rst">2023-10-11 12:05:51 GMT</a></p>
</article>
<nav id="pep-sidebar">
<h2>Contents</h2>
<ul>
<li><a class="reference internal" href="#abstract">Abstract</a></li>
<li><a class="reference internal" href="#pep-acceptance">PEP Acceptance</a></li>
<li><a class="reference internal" href="#rationale">Rationale</a><ul>
<li><a class="reference internal" href="#improving-the-new-user-experience">Improving the new user experience</a></li>
<li><a class="reference internal" href="#enabling-the-evolution-of-the-broader-python-packaging-ecosystem">Enabling the evolution of the broader Python packaging ecosystem</a></li>
<li><a class="reference internal" href="#why-pip">Why pip?</a></li>
</ul>
</li>
<li><a class="reference internal" href="#proposal-overview">Proposal Overview</a></li>
<li><a class="reference internal" href="#explicit-bootstrapping-mechanism">Explicit bootstrapping mechanism</a><ul>
<li><a class="reference internal" href="#security-considerations">Security considerations</a></li>
<li><a class="reference internal" href="#reliability-considerations">Reliability considerations</a></li>
<li><a class="reference internal" href="#implementation-strategy">Implementation strategy</a></li>
<li><a class="reference internal" href="#integration-timeline">Integration timeline</a></li>
<li><a class="reference internal" href="#proposed-cli">Proposed CLI</a></li>
<li><a class="reference internal" href="#proposed-module-api">Proposed module API</a></li>
<li><a class="reference internal" href="#invocation-from-the-cpython-installers">Invocation from the CPython installers</a></li>
<li><a class="reference internal" href="#installing-from-source">Installing from source</a></li>
<li><a class="reference internal" href="#changes-to-virtual-environments">Changes to virtual environments</a></li>
<li><a class="reference internal" href="#documentation">Documentation</a></li>
<li><a class="reference internal" href="#bundling-ca-certificates-with-cpython">Bundling CA certificates with CPython</a></li>
<li><a class="reference internal" href="#automatic-installation-of-setuptools">Automatic installation of setuptools</a></li>
<li><a class="reference internal" href="#updating-the-private-copy-of-pip">Updating the private copy of pip</a></li>
<li><a class="reference internal" href="#updating-the-ensurepip-module-api-and-cli">Updating the ensurepip module API and CLI</a></li>
</ul>
</li>
<li><a class="reference internal" href="#uninstallation">Uninstallation</a></li>
<li><a class="reference internal" href="#script-execution-on-windows">Script Execution on Windows</a></li>
<li><a class="reference internal" href="#recommendations-for-downstream-distributors">Recommendations for Downstream Distributors</a></li>
<li><a class="reference internal" href="#policies-governance">Policies &amp; Governance</a><ul>
<li><a class="reference internal" href="#backwards-compatibility">Backwards Compatibility</a></li>
<li><a class="reference internal" href="#security-releases">Security Releases</a></li>
<li><a class="reference internal" href="#licensing">Licensing</a></li>
</ul>
</li>
<li><a class="reference internal" href="#appendix-rejected-proposals">Appendix: Rejected Proposals</a><ul>
<li><a class="reference internal" href="#changing-the-name-of-the-scripts-directory-on-windows">Changing the name of the scripts directory on Windows</a></li>
<li><a class="reference internal" href="#including-ensurepip-in-python-2-7-and-3-3">Including ensurepip in Python 2.7, and 3.3</a></li>
<li><a class="reference internal" href="#automatically-contacting-pypi-when-bootstrapping-pip">Automatically contacting PyPI when bootstrapping pip</a></li>
<li><a class="reference internal" href="#implicit-bootstrap">Implicit bootstrap</a></li>
<li><a class="reference internal" href="#including-pip-directly-in-the-standard-library">Including pip directly in the standard library</a></li>
<li><a class="reference internal" href="#defaulting-to-user-installation">Defaulting to –user installation</a></li>
</ul>
</li>
<li><a class="reference internal" href="#references">References</a></li>
<li><a class="reference internal" href="#copyright">Copyright</a></li>
</ul>
<br>
<a id="source" href="https://github.com/python/peps/blob/main/peps/pep-0453.rst">Page Source (GitHub)</a>
</nav>
</section>
<script src="../_static/colour_scheme.js"></script>
<script src="../_static/wrap_tables.js"></script>
<script src="../_static/sticky_banner.js"></script>
</body>
</html>
Reference in New Issue View Git Blame Copy Permalink