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

Mon Nov 20 19:32:13 EST 2017

On Mon, Nov 20, 2017 at 3:24 PM, Paul Moore <p.f.moore at gmail.com> wrote:

> On 20 November 2017 at 21:59, Chris Barker <chris.barker at noaa.gov> wrote:
> > I don't understand any of this enough to have an opinion, so while I'd
> like
> > to see py.exe be renamed python.exe, let's not let "the perfect be the
> enemy
> > of good enough". So, if someone can make the case that they can
> restructure
> > the whole py.exe / python.exe thing nicely in a way that will work, AND
> > write the code to do it fairly quickly, then great!
>
> I'm happy enough to modify the py.exe code to base its behaviour on
> the name it's called with, as Steve suggested. I'm not sure if that
> would require a PEP, but I'm willing to do one if it's felt that there
> is a need. It should be possible to get that change in for 3.7.

very cool -- thanks!

> I
> don't know what would be the best approach for adding copies/links of
> the launcher under other names, though.

this is the thing -- I wonder if py.exe has been a success at all :-)

I honestly don't know - it's a cool idea, and I liked the idea of replacing
the #! line and all that, but the truth is that people simple don't write
scripts on Windows and expect them to "just work" the same way they do on
*nix systems. And if you do distutils/setuptools "scripts" or "entry
points" or whatever we are calling them, right, then you can write utility
scripts and install them, and use them....

So ti comes down to: does anyone USE py.exe???

The fact that it's unique to Windows  makes it simply less discoverable,
and the fact that Windows users aren't used to the whole #! line thing,
means that as useful as it might be, it's not getting actual use.

In fact, I happened to be paying a lot of attention to this conversion
because at the very same moment, a group of us are developing a python
curriculum, and working on the "how to run a python file" part. We are
producing platform specific instructions, but decided NOT to include the
py.exe option for Windows users .. just more confusing things among a lot
of confusing things!

So who does teach people about it???

Anyway, this whole thread has been about making the experience more
platform-independent -- ideally users should see docs without
Windows-specifc advice, and have it "just work" -- having a python3.exe
would make that more likely, so let's do that.

If we could py.exe enhanced and then use it instead of python.ex,m that
would be great. Though I at least still have no idea of that's possible.

But I don't see why we couldn't make a pyton3.exe NOW (in py3.7) that is a
copy (Or link, still don't get linking on Windows...) of python.exe, that
would help the situation, and if at some point the in the future,
python.exe, python3.exe and py.exe all become the same thing, great!

> I think the launcher change is worthwhile in its own right. Even if we
> don't install any aliases by default, users will be able to manually
> add them.

sure -- but no one would -- or not really no one, but it would become maybe
even a worse hassle of the same thing not working everywhere.

we need th=e basic advice given out to *nix users to work:

if you type "python" at the command line, and get python2, then you can
type "python3" to get python 3.

simple, straightforward, and it CAN help.

> > Otherwise, let's at least get a python3.exe into 3.7 -- and ideally into
> > updates to 3.5, 3.6, and (python2.exe in this case, 2.7)
>
> It's not going to be acceptable for 3.5, as that is now in security
> fix only mode. I'm not certain it's even acceptable for bugfix-only
> releases. It's a backward incompatible change (3.6.3 has no
> python3.exe but python 3.6.4 does) but maybe an acceptable one - we'd
> need feedback from the 3.6 and 2.7 release managers on that.
>

Fine -- we can leave that for future discussion....

> Also, I'm assuming here you mean "create a copy of python.exe called
> python3.exe". If we do that, we risk making it harder to later switch
> to making "python3.exe" a link to the launcher - for the same reason
> that making "python.exe" be an alternative name for the launcher is
> problematic right now.
>

I'm lost -- how does it make it any harder, rather than exactly the same ???
(except two changes, rather than one...but they are the same change)

> And maybe make "add to PATH" be the default in the installer.
>
> I'm not willing to contradict Steve on this one.

I didn't know he'd made a clear statement about it.

But if people that understand these things say it's a bad idea, then it's a
bad idea. But we SHOULD make sure we are considering not just what could go
wrong, or how often it could go wrong, but who it is going to go wrong
for...

i.e. making it "do the right thing" for newbies is much more important that
making sure it doesn't "do the wrong thing" for more experienced folks that
can uncheck a box, or clean up their PATH after the fact....

There are too many
> not-uncommon cases that we could mess up badly here. It's the right
> choice for "make new users' experience as easy as possible", but if we
> do this at the cost of making the experience of people upgrading to
> 3.7 (possibly by installing 3.7 to gradually switch over,

then you uncheck the box -- and if someone is installing 3.7 to test it
out, they SHOULD be a experience enough to uncheck a box...

> or starting
> their migration from 2.7 with 3.7) unpleasant,

why would that be a problem????

Though we may need a "python2.exe" executable for that to work well :-(

> The history of how we added Python to PATH across various versions is
> messy and inconsistent. Add to that other distributions (Anaconda,
> ActiveState) making different choices and adding yet more
> inconsistency, means that anyone who *isn't* a brand new user probably
> already has a tweaked, and likely fragile, setup.

We're not doing them
> any favours by adding another new behaviour.

I'm not trying to do them any favors -- I'm trying to do the favors for the
newbies.. and YES, at the expense of people with "tweaked, and likely
fragile, setup."

> We need *another* solution here. Not just variations on the existing
> mess. That's why I like Steve's suggestion of making the launcher into
> the canonical entry point.

only if it's named "python" (and python3) -- what we DON'T need is a
different way to do it on Windows -- that's what we tried, and I thin it's
failed.

It's not easy, but at least it stands a
> chance of breaking out of the cycle we're currently in, of switching
> back and forth between "add to PATH" and "don't add to PATH".
>

It also seems completely orthogonal to the "add to PATH" question -- having
this nifty new launcher setup, but not on a newbies PATH where they can use
it, isn't going to help at all.

> > Those are quick and simple to do, result in little disruption, and make
> the
> > whole cross-platform thing more manageable.
>
> They aren't that simple. I've already discussed "add to PATH". And if
> we add python3.exe, we have to consider questions like will venv be
> modified to include it in virtual environments? Will virtualenv?

what do those systems do on *nix? do exactly the same thing on Windows.
Done.

Also -- I don't much care -- I want newbies that aren't using virtual
environments to have a better expeience -- virtualenv pretty much solves
this issue IF they are being used.

> "Although never is often better than *right* now" is the relevant
> Zen here, not "Now is better than never" (nobody's suggesting we
> *never* fix this).

if we take long enough, everyone will be using python3 anyway :-)

-CHB

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20171120/595155b4/attachment-0001.html>