- remove proposal to change the script installation directory on
Windows due to the backwards incompatility issues pointed out
by Paul Moore
- include an explicit requirement to resolve the requests
certificate management issues prior to beta 2
- cleaner formatting of the integration timeline
- timeline based on discussion with the 3.4 release team
and the pip devs
- also clarified the two trust models on offer (i.e. that
the PEP ensures trusting PyPI remains explicitly opt-in, just
as it has always been in the past)
- all functional changes are now 3.4 only
- still proposes docs changes for 2.7 & 3.3
- notes current effort to create a Windows installer for pip
- notes possibility of a future PEP to provide a combined
CPython 2.7, pip and Python Launcher installer from python.org
I realised after the last round of reviews that a *big* chunk of the
rationale for this PEP was assumed knowledge on distutils-sig, and
this lead directly to the high rate of replies on python-dev that
just didn't get why the requested exemption to include the new
feature in Python 2.7.6 is so important.
The PEP now attempts to do a better job of bridging that gap, as
well as further expanding on how having the ``ensurepip`` module
fully public in older releases should actually make things *less*
confusing, rather than more, since it gives us a location to
explain the alternative fallback bootstrapping methods.
Combined update with changes from both Donald and I
- adjust the abstract to emphasise the fact this is first about
recommending pip as the official installer, and only then
about trying to ensure it is made readily available to users
- note in the rationale that this is a key stepping stone towards
decoupling the release cycle of the language from that of the
PyPI software distribution ecosystem
- expanded proposal overview (including explaining the logic that
leads from recommending pip to providing it by default)
- note the benefit of being able to test the bootstrap using the
existing buildbot fleet
- note the three known use cases for invoking ensurepip directly
- a little more detail on the required documentation updates
- be clear that easy_install *will* be installed by default, but
that problem will go away once pip eliminates their setuptools
dependency
- greatly expand on the rationale for including ensurepip in the
2.7 and 3.3 maintenance releases, including an explanation of
the origins of the current policy in the 2.2.x series, how the
current proposal differs from those, and why this shouldn't
open the floodgates to more requests for exemptions
- mention multiple commercial Python redistributors rather than
just the one
- clarify various issues in the recommendations for downstream
redistributors
- note the licenses for the bundled software
- explain rationale for not making this an installer-only change
in 2.7 and 3.3
- explain rationale for keeping the ensurepip module public in
2.7 and 3.3
- assorted cleanups to grammar and wording
- use the module name Antoine suggested
- list the five distinct parts of the proposal when
describing the implementation strategy
- note the bootstrap approach makes it easy to let people opt-out
- allow distros to redirect a global ensurepip invocation to the
system package manager
- decide the open questions in favour of the currently documented
approaches (i.e. no changes to uninstallation, update the
directory layout and PATH handling on Windows)
- added a new security considerations section
- writing that made it clear it made more sense to just always
install from the private copy, and leave all network access
to the extracted pip
- this design change meant the original module name was no longer
suitable, so it was changed to ``extractpip`` instead
- incorporated Van Lindberg's suggestion from a while back to
rename Tools\Scripts on Windows to bin
- add MvL as BDFL-Delegate
- clarify that pip is made available by default
- miscellaneous updates to the rationale section
- include a rationale for choosing pip over other tools
- consolidate all the technical details under one heading
- be explicit about the proposed getpip.bootstrap API
- be explicit about the proposed venv API changes
- be explicit about the proposed installer semantics
- be explicit about the documentation impact
- restrict getpip additions to off-by-default security
enhancements (enabled by the installers and pyvenv)
- clarify the Windows PATH is only modified when the relevant
installer option is checked
- request that downstreams that *don't* provide pip at least properly
document that fact
- avoid the term "bundled" (favouring "private copy" or "bootstrapped"
as appropriate)
- name the Python Packaging Authority explicitly in the governance
section and point out that umbrella group now also includes the PyPI
and setuptools maintainers (and more) in addition to the original
group of pip and virtualenv maintainers
- note the hassles CPython has had in the past regarding "externally
maintained" modules
- note why we're not pursuing the idea of bootstrapping into the
user site packages by default
- revert to being explicitly 3.4 only (with rationale)
- open question re uninstallation
- open question re script execution on Windows
- explicit cover handling of the setuptools dependency
- spell out the proposed CLI options for getpip
- note that venv will also support --no-download
- explicitly note that pip may gain new features in CPython
maintenance releases and continues using its own release
cycle
- explicitly note that bundling pip doesn't preclude the
use of alternate installers, but instead better *enables*
them by making them easier to bootstrap
- note we should update to new pip version when they're
released, so the release process just checks they're up to
date.
Nick Coghlan
Barry Warsaw
Donald Stufft
Brett Cannon