[Distutils] The future of invoking pip

[Donald Stufft]

On November 5, 2015 at 9:22:14 PM, Ben Finney (ben+python at benfinney.id.au) wrote:
> Donald Stufft writes:
>  
> > On November 5, 2015 at 8:04:41 PM, Robert Collins (robertc at robertcollins.net) wrote:  
> >
> > > cat > /usr/bin/pip << EOF
> > > python -m pip $@
> > > EOF
> > >
> > > Seriously - isn't the above entirely sufficient?
> >
> > It’s not particularly hard to do this (we could even make a pip-cli
> > package on PyPI that did it). It’s just one more step and one more
> > “weird” thing for newcomers.
>  
> You seem to be saying that, for a newcomer wanting to invoke Pip, that
> the command ‘pip’ is weird, but that the command ‘python -m pip’ is less
> weird.
>  
> If so, I think you have lost touch with Python newcomers's perspective.
>  
> If not, I don't know what you mean by a simple ‘pip’ command being “one
> more “weird” thing for newcomers”.

No. I mean having the “pip” package on PyPI not provide the ``pip`` command, but instead have them expected to either install another package (pip-cli?) or needing to make their own shim (or shell alias) in order to have the ``pip`` command.

I think that on paper, python -m pip is probably superior to trying to do something in pip to “select” the right version of Python (whether it be via naming scheme of the pip command, or a ``-p`` flag or whatever). However I also think that people are not going to be very fond of needing to type ``python -m pip`` instead of ``pip``.

>  
>  
> On the contrary, it is ‘python -m pip’ that is weird to a newcomer, and
> *that* is why I am aghast at the insistent push toward it.
>  
> In order to be friendly to newcomers, and friendly to people who use
> more than just Python, the Python tools should not have UIs that assume
> they are the centre of everything.

Well, Python *is* the center of everything for pip… there isn’t much use to pip except to modify a particular Python’s install.

Generally I think that (again on paper) providing “simple” (e.g. unversioned) binaries is the correct approach for anything where the particular Python that is being used to invoke it isn’t important (or that it’s even Python that is invoking it). Something like Mercurial would fall into this category.

I’m not really sure what the right answer is for something where the particular version of Python you’re invoking it with (and that you’re actually using Python) is important. python -m makes a lot of sense in that area because it eliminates the need to have each tool create their own logic for determining what python they are operating on but I think most people are not going to be very familiar with the idea and I don’t know how well they’d warm to it. The other option (that I can come up with) is baking that logic into each tool (as pip and virtualenv do now) either via naming scheme or a flag.

If I had a particularly great answer I’d be strongly advocating for one over the other. As it stands, I can’t really decide if ``python2.7 -m pip`` or ``pip -p python2.7`` is better.

>  
> The ‘python -m foo’ syntax is a peculiarity of Python, is not at all
> intuitive for anyone already familiar with their operating system nor
> with other languages.
>  
> The push away from simple command executables and toward the bizarre
> ‘python -m foo’ is a wart that needs to be minimised, not encouraged.
>  
> Instead, the tools should go to considerable effort to *work with* the
> operating system in which they find themselves, and that includes having
> a UI that works like other tools.
>  
> In this case: if the user wants to use “pip”, then the command to invoke
> should not be ‘python -m pip’ but instead should be ‘pip’.
>  
> --
> \ “I have always wished for my computer to be as easy to use as |
> `\ my telephone; my wish has come true because I can no longer |
> _o__) figure out how to use my telephone.” —Bjarne Stroustrup |
> Ben Finney
>  
> _______________________________________________
> Distutils-SIG maillist - Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>  

-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA