Steve Dower added the comment:
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
Petr Viktorin added the comment:
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
Chris Withers added the comment:
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?
--
Nick Coghlan added the comment:
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
Nick Coghlan added the comment:
(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
New submission from Chris Withers :
$ python3.7 -m ensurepip --upgrade
Looking in links: /var/folders/m6/tsd59qsj7pd_lldh4mhwh6khgn/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)
