$ python3.7 -m ensurepip --upgrade
Looking in links: /var/folders/m6/tsd59qsj7pd_lldh4mhwh6kh0000gn/T/tmpqk_vncev
Requirement already up-to-date: setuptools in /Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages (39.0.1)
Requirement already up-to-date: pip in /Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages (18.1)

But:

$ python3.7 -m venv /tmp/test_venv
$ /tmp/test_venv/bin/pip --version
pip 10.0.1 from /private/tmp/test_venv/lib/python3.7/site-packages/pip (python 3.7)

(Added packaging, Linux distro, and Windows and macOS installer folks to the cc list)

Chris and I were discussing this behaviour, and it turns out even I had forgotten how we had specified this feature in PEP 453: `ensurepip --upgrade` ensures that an older pip is brought up to date with the bundled version, but it does *not* check PyPI for the latest version the way that `python3 -m pip install --upgrade pip` does.

We both expected the ensurepip option to behave the same way as the pip option, since they share a name.

If I had the time machine keys, I'd use a more verbose name for the ensurepip flag (e.g. `--upgrade-to-match-bundle`) to help make it clearer that it does something different from the corresponding pip flag.

As it is though, for Python 3.9, I think we should change the behaviour of `--upgrade` to imply `python -m pip install --upgrade pip`, and then add a separate `--network-upgrade`/`--no-network-upgrade` option that allows folks to opt out of the PyPI part of the version check.

The make file would presumably be updated to pass the `--no-network-upgrade` flag, and I guess the macOS and Windows installers would as well (I'm not sure what the platform policies are around installers making random additional requests to external network services)

Addressing the other part of Chris's initial post: there's also no `--upgrade-pip` option on `venv` itself.

Instead, there's only an `--upgrade` option that is intended for *Python* version upgrades, and restructures the internal layout of the venv to switch the Python major version number.

Unless you're using a Linux distro Python that has been patched to inject the external pip installation with rewheel or dirtbike, getting a venv that uses the externally updated version of pip requires running `python3 - m venv --system-site-packages --without-pip ...`.

So my suggestion there would be to:

- rename "venv --upgrade" to "venv --set-interpreter" (keeping `--upgrade` as a legacy alias)
- default to running `ensurepip --upgrade` with its new behaviour
- add `--network-upgrade/--no-network-upgrade` options which get passed straight through to the updated ensurepip

I don't suppose there's any chance we can treat the misnaming of these options as the bugs they feel like, so so fix them for 3.7+, rather than having people battle on with the confusion for another 3+ years until 3.9 is mainstream?

Please don't forget that it is possible to use venv without PyPI.

With my Fedora hat on: as a distro, we don't trust PyPI as a package delivery infrastructure. Lots of users do, and we allow the users to easily but explicitly opt in to trusting it by running "pip install". (In the same way, we don't trust rubygems, npm, CPAN, hackage, etc. -- there are too many, and PyPI is not special.)

Changing venv's existing `--upgrade` option to start installing from PyPI is problematic. We'd probably need to patch it out, creating an inconsistency between the distro and upstream: it would not do what `python3 -m pip install --upgrade pip` does.

ISTM, the proposed semantics aren't consistent: "venv --upgrade" would not match what "pip --upgrade" does: it would do what "pip install --upgrade pip" does. The latter needs an extra argument, explicitly saying *what* to upgrade. Making "pip" implicit makes sense for "ensurepip", but not for "venv".

Also, in my view, "network" should not be used as a synonym for PyPI (outside pip).

Could we instead make `venv --upgrade` print out a warning, saying that it upgrades Python, and to upgrade pip you should `python -m pip install --upgrade pip` instead?

---

> Unless you're using a Linux distro Python that has been patched
> to inject the external pip installation with rewheel or dirtbike,
> getting a venv that uses the externally updated version of pip
> requires running
> `python3 - m venv --system-site-packages --without-pip ...`.

FWIW, "rewheel" is no more: Fedora now distributes the wheels themselves, and patches system ensurepip to look in /usr/share/python-wheels/.

I'm with Petr here. ensurepip/venv should only go as far as we support, which is the version of the wheels included in our bundle. We should continue having the stdlib pretend that PyPI doesn't exist.

External network access would justify the longer option, in my opinion: "--upgrade-pip-from-pypi"