<p dir="ltr"><br>
On 20 Aug 2013 11:02, "Steve Dower" <<a href="mailto:Steve.Dower@microsoft.com">Steve.Dower@microsoft.com</a>> wrote:<br>
><br>
> Brett Cannon wrote:<br>
> > Steve Dower wrote:<br>
> >> Oscar Benjamin wrote:<br>
> >>> Paul wrote:<br>
> >>>> Given that the installer includes the py.exe launcher, if you leave the<br>
> >>>> defaults, then at a command prompt "python" doesn't work. But that's fine,<br>
> >>>> because "py" does. And if you have multiple versions of Python installed, you<br>
> >>>> don't *want* python on PATH, because then you have to manage your PATH. Why<br>
> >>>> bother when "py -2.7" or "py -3.3" does what you want with no path management?<br>
> >>>> Once you want any *other* executables, though, you have to deal with PATH<br>
> >>>> (especially in the multiple Pythons case). That is a new issue, and one that<br>
> >>>> hasn't been thought through yet, and we don't have a good solution.<br>
> >>><br>
> >>> From a user perspective I think that 'py -3.4 -m pip ...' is an improvement as<br>
> >>> it means I can easily install or upgrade for a particular python installation (I<br>
> >>> tend to have a few). There's no need to put Scripts on PATH just to run pip. I<br>
> >>> think this should be the recommended invocation for Windows users.<br>
> >> Crazy idea:<br>
> >><br>
> >>     py install <other args><br>
> >> (or 'py --install ...', but I think 'py install' is currently invalid and could be used?)<br>
> >><br>
> >> which the launcher executes identically to:<br>
> >><br>
> >>     py -m pip install <other args><br>
> >><br>
> >> (Implicitly extended to other relevant commands... I'm not proposing a complete list.)<br>
> >><br>
> >> Pros:<br>
> >> * allows implicit bootstrapping on first use (from a bundled pip, IMO, in case no network is available)<br>
> ><br>
> > Nick already killed this idea. Richard's original PEP proposed this and the idea eventually was shot down.<br>
><br>
> Are you referring to the whole idea or just the implicit bootstrap? I followed the discussions about the latter, and it seemed that the problem was trying to bootstrap pip using pip.</p>
<p dir="ltr">That and potentially relying on network access at runtime, as well as potentially running into permissions issues depending on where Python was installed. Implicit bootstrap just seems like a recipe for hard to debug failure modes.</p>

<p dir="ltr">> This is different (bootstrap pip from py) and I believe it does not have the same issues.</p>
<p dir="ltr">It certainly avoids some of them, but not all.</p>
<p dir="ltr">I think Paul Moore has the right idea: treat "scripts on Windows" as a distinct problem deserving of a separate PEP. That general solution will then apply to pip as well. In the meantime "py -m pip" feels like a tolerable Windows specific workaround.</p>

<p dir="ltr">Cheers,<br>
Nick.</p>
<p dir="ltr">><br>
> > -Brett<br>
><br>
> _______________________________________________<br>
> Distutils-SIG maillist  -  <a href="mailto:Distutils-SIG@python.org">Distutils-SIG@python.org</a><br>
> <a href="http://mail.python.org/mailman/listinfo/distutils-sig">http://mail.python.org/mailman/listinfo/distutils-sig</a><br>
</p>