In creating the next draft of PEP 453, I noticed an odd quirk of the
proposed "pyvenv --no-download" option: it bootstraps the version of
pip *that was provided with Python*, rather than the version currently
installed in the base Python installation.
That seems incredibly strange to me, and I expect it will confuse
users as well. "I'm using Python 3.4 and have upgraded pip to 1.6, but
my virtual environments are only getting pip 1.5 when I use the
'--no-download' option. HALP!".
Rather than doing any complicated trickery to make it make sense, I'm
considering two comparatively simple changes:
1. Change the proposed "--no-download" option for getpip and pyvenv to
"--internal-only"
2. Change the getpip API to pass all other options through to pip
install, rather than only defining a supported subset
That way the behaviour with the flag set makes slightly more intuitive
sense (since that flag will be documented specifically as forcing
installation from the getpip module's internal copy of pip)
If users want to use the more advanced features of pip when
bootstrapping their virtual environments (like installing from a
prebuilt wheel rather than the stdlib internal copy or from PyPI),
then the recommended approach will be to use the ``--without-pip``
option to ``pyvenv`` itself, and then run ``getpip`` directly after
activating the virtual environment.