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. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia