- 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.
Donald Stufft
Nick Coghlan
Brett Cannon