On Wed, Sep 18, 2013 at 10:26 AM, Nick Coghlan <ncogh...@gmail.com> wrote:
> 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. > Both sound reasonable to me.
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
