Author ncoghlan
Recipients barry, cjw296, doko, dstufft, ncoghlan, ned.deily, paul.moore, petr.viktorin, steve.dower
Date 2019-06-09.04:58:58
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
(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)
Date User Action Args
2019-06-09 04:58:58ncoghlansetrecipients: + ncoghlan, barry, doko, paul.moore, cjw296, ned.deily, petr.viktorin, steve.dower, dstufft
2019-06-09 04:58:58ncoghlansetmessageid: <>
2019-06-09 04:58:58ncoghlanlinkissue37107 messages
2019-06-09 04:58:58ncoghlancreate