[Python-ideas] High time for a builtin function to manage packages (simply)?

[Nathaniel Smith]

On Wed, Sep 9, 2015 at 1:56 AM, Paul Moore <p.f.moore at gmail.com> wrote:
> 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...)

At the very least, surely this could be "fixed" by detecting this case
and exiting with a message "Sorry, Windows is annoying and this isn't
going to work, to upgrade pip please type 'python -m pip ...'
instead"? That seems more productive in the short run than trying to
get everyone to stop typing "pip" :-). (Though I do agree that having
pip as a separate command from python is a big mess -- another case
where this comes up is the need for pip versus pip3.)

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

It sounds like this is another place where in the short term, it would
help a lot of pip at startup took a peek at $PATH and issued some
warnings or errors if it detected the most common types of
misconfiguration? (E.g. the first python/python3 in $PATH does not
match the one being used to run pip.)

-n

-- 
Nathaniel J. Smith -- http://vorpus.org