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

[Steve Barnes]

On 21/11/2017 00:32, Chris Barker wrote:
> On Mon, Nov 20, 2017 at 3:24 PM, Paul Moore <p.f.moore at gmail.com 
> <mailto:p.f.moore at gmail.com>> wrote:
> 
>     On 20 November 2017 at 21:59, Chris Barker <chris.barker at noaa.gov
>     <mailto: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 agree that it would be.

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

A lot of people, on windows, are using py.exe and pyw.exe without 
realising it - the default behaviour of the recent installer is to 
associate py.exe with *.py and pyw.exe with *.pyw so any user that is 
running python code by just typing the name of the file, or double 
clicking it, will be using it.

This is the equivalent of the Unix chmod + shebang - I don't think that 
Windows users are ready for chown/chmod.
> 
> 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???
> 
As above.

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

I quite regularly give people python courses and I always, regardless of 
target platform, tell them about the shebang and encoding lines, explain 
why they need them, including many editors basing syntax highlighting 
and character handling on them. I also point out that some nasty person, 
(me), has embedded the requirement to use them in the company coding 
standard for python and the review criteria for all code. (So carrot and 
stick).

> 
> 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.
> 
One of the nice things about embedding the behaviour into the launcher 
is that if the user/admin has installed a python that includes it it 
provides the behaviour for python installations that were already 
present and discoverable even if they didn't have it so if you have 
python 2.5 then after you install something with py.exe you can, 
currently, use py -2.5 to run it, (or py -2 if it is the only python 2).


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

I am not sure that I spelt it out well enough but my personal feeling is 
that the installer should, (and I am reasonably sure that it should 
capable of this), default to add to path IF there is not a currently 
available python, (discoverable), and either default to don't add or 
prompt the installer if there is.

Of course the whole add to path or not becomes moot if the py.exe 
launcher is present as it is installed on the path, (C:\Windows), and 
then tries very hard just to "do the right thing".
> 
> 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 <mailto:Chris.Barker at noaa.gov>

-- 
Steve (Gadget) Barnes
Any opinions in this message are my personal opinions and do not reflect 
those of my employer.

---
This email has been checked for viruses by AVG.
http://www.avg.com