On Sep 18, 2013, at 10:26 AM, Nick Coghlan
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"
I think this one makes the most sense, although --bundled or something sounds better than --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 _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA