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