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

[Paul Moore]

[Excuse any attribution errors, the quoting appears to have got badly
messed up somehow]

On 21 November 2017 at 06:21, Steve Barnes <gadgetsteve at live.co.uk> wrote:
>
> On 21/11/2017 00:32, Chris Barker wrote:
>>     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.

I use the py launcher a lot. Often just as "py" or "py -3.6". It
certainly isn't just limited to use via shebang lines.

I will say that I don't see beginners using it as much. That's
probably because there's so much documentation that says "use the
python command to start Python". That is of course an argument that we
should make the canonical command "python" rather than "py", but it
doesn't mean that if people find the "py" command they won't use it.
There's not a lot of evidence that isn't anecdotal either way on that
latter point.

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

And me.

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

Um, we need the basic advice given to *everyone* to work. Insisting
that advice has to be "what Unix people do right now" is not the only
option. The advice "use python to run your default Python interpreter"
is too entrenched to change. The python2 and python3 aliases are a
platform-specific hack to get around the fact that some Linux
distributions couldn't switch the default Python to Python 3. Most of
the beginners I work with have no experience on Unix and no awareness
of python2/python3 commands.

"If you run python at the command line and get the wrong version of
Python, then..." - In that case you already have multiple versions of
Python on your system, and by the definitions we've been working to
here, you're an advanced user so you can fix it yourself.

Obviously, that's too harsh a stance for us to take. But let's not
ignore the fact that Unix users are typically *already* having to deal
with multiple versions of Python, and are typically more familiar with
command lines than Windows users. So there's no guarantee that a
solution that works for them is usable for Windows users who've never
used Python or the command line before, who downloaded Python 2.7 and
installed it, were then told "no, you should be using Python 3", and
installed 3.7, and now don't understand why "upgrading" didn't
uninstall the old version, what they need to do to work with Python 3,
etc...

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

+1. This is the biggest benefit for me. Also the fact that all the
older Python versions *don't need to be on PATH*. Having multiple
versions of Python on PATH is a bad thing (because of the Scripts
directory - if you want, I can explain in detail, but it's a side
issue for now).

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

My apologies - I was unclear. I meant Steve Dower, who maintains the
installer, and who has strongly stated that the way the Windows PATH
works (separate system and user parts) makes sensible "add to PATH"
behaviour impossible. The reasons have all been described multiple
times, and I won't go into them again. Search the archives if you want
to see the details. Suffice it to say that wishing it was easy to
"just add Python to PATH" doesn't make it so...

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

That's why I prefer this option. There are still issues to address
(such as the Scripts directory), but it's much easier to keep the
complexity manageable with this approach.

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

But I (as an advanced user) don't *want* to uncheck the box. I *do*
want 3.7 to be my default Python. But if I previously had 2.7 as my
default, and that's in the *system* part of PATH, then checking the
box *doesn't work* - Python 2.7 is still my default. OF COURSE I have
enough knowledge to fix the issue. That's not my point. My point is,
do we want experienced Python users' first experience with Python 3.7
to be "the installer didn't work right", or "installing 3.7 broke my
system, and I had to fix it manually", or something similar?
Experienced Python users on Windows have been remarkably tolerant over
recent years of our continual changing of where we install Python,
whether we add to PATH by default, etc. At some point we need to stop,
think things through, and get it right once and for all. Or at least
agree to stick with what we decide for longer than a couple of
releases.



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

OK. Maybe "not doing them any favours" is not as well known a phrase
as I thought, sorry. What I meant was we're repeatedly penalising such
users and we need to stop. We don't need to cater for their specific
environments (they know how to do that themselves, and have done so).
But we do need to stop breaking their setup every release.

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

"python" yes. Not so much "python3", which I don't believe is a
solution anyone *likes* - it's just an expedient for a specific Unix
issue. (If you don't believe me, there's plenty of issues on the pip
tracker that boil down to Unix users getting confused over which
Python version they are executing, so certainly "python3" isn't a
perfect solution, or even a particularly good one IMO).

Paul