<div dir="ltr">On 19 August 2013 22:37, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 19 August 2013 10:08, Paul Moore <<a href="mailto:p.f.moore@gmail.com">p.f.moore@gmail.com</a>> wrote:<br>
> 2. We need to be careful to define exactly when and how the "pip" command is<br>
> present. Don't forget that on Windows, the "python" command is not on PATH<br>
> by default (and the existence of the launcher means that it really doesn't<br>
> need to be). I would suggest that we say something like "The pip command<br>
> will be installed alongside the python command, and will be available when<br>
> python is"[1]. We should also probably note that versioned variants of pip<br>
> will be provided matching the versioned copies of the python command that<br>
> are available (e.g., pip3/pip3.4 on Unix, maybe none at all on Windows...).<br>
> Unless of course we want to use a different scheme for pip, in which case we<br>
> need to agree on what that will be.<br>
<br>
</div>In 3.3+, I believe the Windows installer does PATH modification by<br>
default. In 3.4+ it will likely do PATHEXT modification, too.<br></blockquote><div><br></div><div>"Add python to PATH" is off by default. And I think it only adds C:\Python33 to PATH, not C:\Python33\Scripts (which isn't even created by the installer). I haven't tested this, though.</div>
<div><br></div><div>PATHEXT modification is handled by the code for "Register Python extensions" which is on by default. But that's separate from "add python to PATH".</div><div><br></div><div>Given that the installer includes the py.exe launcher, if you leave the defaults, then at a command prompt "python" doesn't work. But that's fine, because "py" does. And if you have multiple versions of Python installed, you don't *want* python on PATH, because then you have to manage your PATH. Why bother when "py -2.7" or "py -3.3" does what you want with no path management? Once you want any *other* executables, though, you have to deal with PATH (especially in the multiple Pythons case). That is a new issue, and one that hasn't been thought through yet, and we don't have a good solution.</div>
<div><br></div><div>There's a reason that python.exe was not on PATH by default for all these years. The launcher let us avoid most of the issues, and having it optional and off by default solved most of the remaining issues. But all of the problems still apply equally to pip.exe - and we don't have workarounds/solutions yet for that.</div>
<div><br></div><div>At a minimum, if you want to set PATH to include C:\Python33;C:\Python33\Scripts by default, this should be proposed on python-dev. And be prepared for questions like "what if you install multiple Pythons?", "how will uninstall work?", etc. They have been raised before and never answered satisfactorily. TBH, I doubt it'll be resolved in time for beta 1.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> 3. This also begs the question of whether pip.exe gets installed in the<br>
> "Scripts" subdirectory on Windows, as at present - if it does, we'll have to<br>
> be very careful indeed over how we word the instructions, as it's *easy* for<br>
> users to have python.exe on PATH but not have Scripts\pip.exe on there :-(<br>
<br>
</div>We should just add Scripts to the PATH in the installer as well.<br></blockquote><div> <br></div><div>See above.</div><div><br></div><div>I'm -1 on changing any of the current installer PATH handling for Windows as a side-effect of this proposal. I think we need to devise a solution that works with the current behaviour (which might mean installing a pip.exe alongside python.exe, and documenting the command as "pip, if you have python on PATH, otherwise py -m pip").</div>
<div><br></div><div>OTOH, if you want to raise the issue of "fixing" the current Python install layout and process for Windows, then I'd be fine with that. The current layout is messy, and annoyingly different than Unix. But (a) it's an issue for python-dev, and (b) I don't think you should expect that debate to be resolved in time to hold this proposal up for it.</div>
</div><br></div><div class="gmail_extra">Paul.</div><div class="gmail_extra"><br></div><div class="gmail_extra">PS I'm carefully *not* mentioning the differing layout used by virtualenv/venv in the above, because it will muddy the water. But it is probably relevant. And if the system Python is on PATH and you activate a virtualenv, there could be some difficult interactions there - that's why I explicitly don't add my system Python to PATH, or install packages into it. I think we need some end user best practice advice, if we're going to start advocating using a pip installed in the system Python (maybe "always use --user" is enough). Hmm, I'm starting to find more questions than answers here. Time to stop for a while...</div>
</div>