[Python-ideas] Looking for input to help with the pip situation

Chris Barker - NOAA Federal chris.barker at noaa.gov
Tue Nov 14 19:48:40 EST 2017

On Nov 13, 2017, at 1:53 PM, Paul Moore <p.f.moore at gmail.com> wrote:

In principle, I agree with the ideas here, but there are some
practical issues that make them somewhat less straightforward than we
might like.

And practically beats principally ;-)

But yeah.

1) Add python2.exe and python3.exe files to the Windows installers

The only possible way we'd get a python2.exe is by adding it to future
releases of Python 2.7, and we shouldn't be recommending Python 2 for
new users anyway.

No, but it’s going to be in use for a while yet (2020, yes?).

And no, new users should not install py3, but new users may work in an org
that is using py2.

And I'm strongly -1 on promoting "python3.exe" as
the canonical way of getting Python 3.

So what is canonical? Not the py executable, for sure.

*maybe* we are at a point where we expect py3 to be the default on most
systems, but we DO need a way to tell people how to get py3 if:

Typing python gets them py2.

And it’s not an option to remove py2 or re-configure their systems to
change the default ( see your point below about Windows PATH priorities)

The python3 command is a result
of the Unix issues around switching to Python 3 as the default, and we
shouldn't perpetuate that approach on Windows, where it's unneeded.

But the exact same issues are there in windows (except the shebang line)
bit it’s pretty weird that py.exe respects “python3”, when there is no
python3.exe on the system...

And having multiple systems work the same way IS a laudable goal.

Having said that, I don't object to including versioned executables as
a convenience (if it is one). I just dislike promoting the use of them
via standard documentation.

Totally agree.

 1a) alternatively, we could add a "py" executable to the standard linux

builds, so there would be THAT one way to do it. But I think that's a "BAD

IDEA" --

I think that getting a "py" launcher on Unix is a lost cause at this

Fine — I never liked the idea :-)

Then "python2 -m pip install" would work everywhere (only with new

installations, but at least with newbies, that's a bit more likely ...)

No newcomer should *ever* be getting told to use "python2 -m pip
install". Maybe "python3 -m pip install",

Exactly — that was supposed to be an example. Both should work, but

Python -m pip install would be recommended, with “you can add 2 or 3 if it
doesn’t do the right thing.

 And of course not all Unix distributions come
with Python 3 installed

Exactly — which is why even newbies that install just python 3 end up with
both on their system.

(Mac OS being an obvious example, and I think
Nick mentioned CentOS and RHEL) so python3 won't work everywhere

But it will give you an error, rather that python 2. That’s exactly what we

2) Make adding to the PATH in Windows the default.


Unfortunately, adding Python to the *front* of PATH is not possible.

Well, darn. But we can still make it the default and it will sometimes
work. And all the more reason we need a “python3” executable.

There's also the problem that file associations (i.e., what does
double clicking on a .py/.pyw file do) don't follow the same rules, as
they go through the launcher.

I don’t see anything we can do with that. But I don’t recommend users use
that anyway.

The only really sensible "do what I expect" situation is a single
Python 3 installation on the user's machine.

Sure — but we can’t control that. All we can do is mitigate the damage.

For that case, adding
Python to PATH (it doesn't matter where as there's only one) is a
sensible option. The downside is that optimising for that case makes
the behaviour for other (more experienced) users worse. But it's not
unreasonable to make that trade-off.

Agreed. And not much worse.

3) Make --user be be automatic for pip install. Not actually the default,

but pip could do a user install if you don't have the permissions for a

non-user install.

The problem here is that the user scripts directory isn't on PATH.

How does that have anything to do with it? Either they can launch pip or
they can’t (the above are about that) this is about what should happen when
they do launch pip.

The various options here are under discussion on the pip tracker.

I’ll try to go there to comment.

 but there are
significant backward compatibility and behaviour change issues to
address first.

Always the challenge!

   python myscript.py
   pip install something_or_other

"just work" if the user previously had no Python on their PC.

And as many other configurations as possible :-)

I think the changes we should make should emphasize two things that perhaps
haven’t been given enough priority in the past:

1) things should work as much the same as possible across platforms.

2) making it easier for newbies is more important that for more experienced

It has a whole section at

What I can tell you is that I knew what I was looking for, and didn’t find
in more than a few google searches :-(

Ultimately, though, most newcomers don't read the docs. They muddle
through, ask colleagues who may or may not know any better than they
do, read out of date articles on Stack Overflow ...

Given this, in fact, any changes to documentation and recommended best
practices won’t filter through ‘till after py2’s end of life ... :-(

So really, if we can change behavior to better match what is already
documented — we should. Too late to change best practices.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20171114/7c3b3006/attachment.html>

More information about the Python-ideas mailing list