When bundled the script is supposed to mask the fact you don't have pip installed.
Basically if you type pip3 install requests it will first install setuptools and pip and then pass the command into the real pip. If it was called get pip then the workflow would be "attempt to install", "run get-pip", "rerun the original install command" On Jul 10, 2013, at 8:46 AM, Brett Cannon <br...@python.org> wrote: > > > > On Wed, Jul 10, 2013 at 12:54 AM, Richard Jones <rich...@python.org> wrote: >> On 10 July 2013 14:19, Carl Meyer <c...@oddbird.net> wrote: >> > They certainly do today, but that's primarily because pyvenv isn't very >> > useful yet, since the stdlib has no installer and thus a newly-created >> > pyvenv has no way to install anything in it. >> >> Ah, thanks for clarifying that. >> >> >> > Certainly if the bootstrap is ever ported to 2.7 or 3.2, it would make >> > sense for it to install virtualenv there (or, probably even better, for >> > pyvenv to be backported along with the bootstrap). >> >> I intend to create two forks; one for consideration in a 2.7.5 release >> as "pip" and the other for users of 2.6+ called "get-pip.py". > > Why the specific shift between 2.7 and 2.6 in terms of naming? I realize you > are differentiating between the bootstrap being pre-installed with Python vs. > not, but is there really anything wrong with the script being called pip (or > pip3 for Python 3.3/3.2) if it knows how to do the right thing to get pip up > and going? IOW why not make the bootstrap what everyone uses to install pip > and it just so happens to come pre-installed with Python 3.4 (and maybe > Python 2.7)? > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > http://mail.python.org/mailman/listinfo/distutils-sig
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
