[Python-ideas] High time for a builtin function to manage packages (simply)?
p.f.moore at gmail.com
Wed Sep 9 10:56:39 CEST 2015
On 9 September 2015 at 08:33, Ben Finney <ben+python at benfinney.id.au> wrote:
> Contrariwise, I would like to see ‘pip’ become the canonical invocation
> used in all documentation, discussion, and advice; and if there are any
> technical barriers to that least-surprising method, to see those
> barriers addressed and removed.
There is at least one fundamental, technical, and (so far) unsolveable
issue with using "pip" as the canonical invocation.
pip install -U pip
fails on Windows, because the exe wrapper cannot be replaced by a
process running that wrapper (the "pip" command runs pip.exe which
needs to replace pip.exe, but can't because the OS has it open as the
current running process).
There have been a number of proposals for fixing this, but none have
been viable so far. We'd need someone to provide working code (not
just suggestions on things that might work, but actual working code)
before we could recommend anything other than "python -m pip install
-U pip" as the correct way of upgrading pip. And recommending one
thing when upgrading pip, but another for "normal use" is also
confusing for beginners. (And we have evidence from the pip issue
tracker people *do* find this confusing, and not just beginners...)
Apart from that issue, which is Windows only (and thus some people
find it less compelling) we have also had reported issues of people
running pip, and it installs things into the "wrong" Python
installation. This is typically because of PATH configuration issues,
where "pip" is being found via one PATH element, but "python" is found
via a different one. I don't have specifics to hand, so I can't
clarify *how* people have managed to construct such breakage, but I
can state that it happens, and the relevant people are usually very
confused by the results. Again, "python -m pip" avoids any confusion
here - that invocation clearly and unambiguously installs to the
Python installation you invoked.
In actual fact, if it weren't for the backward compatibility issues it
would cause, I'd be tempted to argue that pip shouldn't provide any
wrapper at all, and *only* offer "python -m pip" as a means of
invoking it (precisely because it's so closely tied to the Python
interpreter used to invoke it). But that's never going to happen and I
don't intend it as a serious proposal.
More information about the Python-ideas