PEP 453 quirk: pyvenv --no-download with an upgraded system pip
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
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
On Wed, 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"
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.
On 18 September 2013 15:26, 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!".
Could the getpip script have a way to update its internal/bundled pip when updating the other pip? Or perhaps an explicit update bundle command? Could getpip be the recommended way to update pip/setuptools generally (perhaps solving some of the other problems that can occur) and always update its bundle? Oscar
participants (4)
-
Brett Cannon -
Donald Stufft -
Nick Coghlan -
Oscar Benjamin