Nathaniel Smith writes:

That seems more productive in the short run than trying to
get everyone to stop typing "pip" :-).

FWIW, I did as soon as I realized python_i_want_to_install -m pip
worked; it's obvious that it DTRTs, and I felt like I'd just dropped
the hammer I'd been whacking my head with.

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

Ah, that's the name of my hammer, although it's come up in 3.2 vs 3.3
as well.

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

I don't understand the logic for trying to save the pip command by
making its environment checking more complex than the app itself.
"python -m pip" suffers from no problems that pip itself doesn't
suffer from, and is far more reliable, without blaming the user.
Sure, people used to using a pip command shouldn't be deprived of it,
but I'll never miss it, and I don't see why anybody who isn't already
using it would miss it.

The only problem with "python -m pip" is discoverability/memorability,
and the fact that interactive use of "from pip import main" is not
properly supported IIUC (not to mention clumsy). Thus the proposal
for a builtin named "install" or similar.

Search Discussions

Discussion Posts


Follow ups

Related Discussions



site design / logo © 2019 Grokbase