[Distutils] What does it mean for Python to "bundle pip"?

[Paul Moore]

On 19 August 2013 22:37, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 19 August 2013 10:08, Paul Moore <p.f.moore at gmail.com> wrote:
> > 2. We need to be careful to define exactly when and how the "pip"
> command is
> > present. Don't forget that on Windows, the "python" command is not on
> PATH
> > by default (and the existence of the launcher means that it really
> doesn't
> > need to be). I would suggest that we say something like "The pip command
> > will be installed alongside the python command, and will be available
> when
> > python is"[1]. We should also probably note that versioned variants of
> pip
> > will be provided matching the versioned copies of the python command that
> > are available (e.g., pip3/pip3.4 on Unix, maybe none at all on
> Windows...).
> > Unless of course we want to use a different scheme for pip, in which
> case we
> > need to agree on what that will be.
>
> In 3.3+, I believe the Windows installer does PATH modification by
> default. In 3.4+ it will likely do PATHEXT modification, too.
>

"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.

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".

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.

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.

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.

> 3. This also begs the question of whether pip.exe gets installed in the
> > "Scripts" subdirectory on Windows, as at present - if it does, we'll
> have to
> > be very careful indeed over how we word the instructions, as it's *easy*
> for
> > users to have python.exe on PATH but not have Scripts\pip.exe on there
> :-(
>
> We should just add Scripts to the PATH in the installer as well.
>

See above.

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").

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.

Paul.

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...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130819/5320d5f2/attachment.html>