[Python-Dev] New Windows installer for Python 3.5

[Paul Moore]

tl;dr We should have "Add this Python to PATH" as a user choice on the
initial installer screen, applicable to whichever install type the
user chooses. Details as to why are below.

On 5 January 2015 at 17:09, Steve Dower <Steve.Dower at microsoft.com> wrote:
> Paul Moore wrote:
>> Steve is in essence saying that it's not possible to sanely manage PATH as part
>> of the new installer, but that py.exe makes that unnecessary.
>
> It's actually not possible to sanely manage PATH from any installer - it really needs to be handled by a user directly (though I can't ever bring myself to tell anyone to use the UI for it). The old installers were less susceptible because they didn't support per-user installs, but you'd still get the "last install Python wins" behaviour.

Agreed. But the current behaviour has "Add Python to PATH" as an
explicit option for the user to choose (I can't recall whether the
default is still not to do so, or if it was changed in 3.4, but that's
a minor issue). People (the minority) who install multiple Pythons
should (IMO) only set this flag on for one Python at most - and I
don't feel obliged to include any special behaviour for anyone who
doesn't follow that rule.

The new installers, with their "One-Click" installs, don't give that
choice. So they are left having to juggle the multiple path entry
problem, without enough input from the user on what he/she wants.

For myself, I'll probably have to use the custom install to get the
control I want. But that's suboptimal, as I probably *want* to use the
new locations, and having to override the "Custom" default of
C:\Python35 to specify "Program Files" is a nuisance. And I bet I'll
install a 32-bit Python in "C:\Program Files" rather than "C:\Program
Files (x86)" at least once, and probably more than once...

Maybe all that's needed is to have an extra checkbox on the first page
saying "Add this Python to PATH" (doesn't matter whether it's on or
off by default). We can warn if it's set on when there's another
Python already on PATH, and warn more vigorously (possibly even an
error) if the other Python will take precedence over the one we're
installing. But I don't think you can avoid giving the user the choice
of whether to put Python on PATH. There are too many bad corner cases
to let the installer guess.[1]

>> My point is that while py handles the interpreter, it doesn't handle things like
>> pip (unless we change the standard usage instructions to say "py -m pip" is the
>> supported approach on Windows).
>
> Or we make pip3.5.exe launch against 3.5 and pip.exe and pip3.exe behave like the launcher, regardless of where they run from.

That would be a change to pip (the wrapper generation code for wheels)
and setuptools (the equivalent code for sdist installs). The launcher
behaviour is more complex to handle, but could be done (at least in
the case of wheels - that uses the distil wrapper code which doesn't
work like the launcher but Vinay could comment on whether that would
be something that could be added). I'm not against this, it's been
mentioned in the past for pip but no-one has had the time or
inclination to work on it.

The alternative is to special-case pip and I'm strongly -1 on that -
this is a general issue for all wrappers.

> For example, say I have Python 3.5 and Python 3.6 installed and PATH=C:\Python35;C:\Python35\Scripts;C:\Python36;C:\Python36\Scripts;... (yes, those are the 'wrong' way around). If I just type "pip" it will run C:\Python35\Scripts\pip.exe, which may or may not be what I expect.

As I say, I don't really care much about supporting this case - my
view is that the user should have only added *one* of the Python
installations to PATH.

> If pip behaved like the launcher, it would find the latest installed version (3.6) and launch pip3.6.exe, which would always run against C:\Python36\python.exe. (How does it do this? No idea yet. Technical details...)

One hard problem - if pip is only installed in Python 3.5, it would
not be able to import pip from the Python 3.6 interpreter because it's
simply not present. I'm not sure this is soluble.

> This might also mean you could write "pip -3.5 install ..." to run against a specific version, but that doesn't have to be supported if it's likely to break scripts by stealing an argument. Since we'll install "pip", "pip3" and "pip3.5", the options are already there.
>
> Would we need "pip3.5-32" as well? This could get out of hand pretty quickly. Perhaps the launcher could include "usepy -3.5" to update the user's PATH for the current session? Would that get any more use? I don't know, but it feels unlikely. There have been multiple requests for the Add to PATH option to be enabled by default in the installer, but frankly it concerns me too much to do so. There are too many effects that most users won't expect.

If we assume there's never more than one Python installation on PATH
(and make it easy for users to stick to this) then most of these
problems go away. The worst is the user install that fails to override
a system install[2] and I don't know much we can do about that except
raise a warning at install time and suggest not adding it to PATH as
it won't work as expected.

Virtualenv has this problem, too, as activating a venv *always* leaves
the venv and the system Python on PATH. But activation is per-process
and can always put the venv at the start, so the bad problems are
avoided.

Paul

[1] Not least if someone who uses Python 3.6 routinely has a need to
quickly install 3.5 to check a bug report - having to do a full custom
install just to not get bitten by the "last install wins" rule is a
lousy user experience.
[2] The other problem case is a user who's had 3.5 installed on PATH
who later installs 3.6 when it comes out and wants to switch to that.
If the user is upgrading, the uninstall of 3.5 will remove it from
PATH so all is fine. Only if the user wants to keep both versions is
there an issue, and in that case I'd be happy enough to assume they
could use the system PATH editor (or do a "change" on the 3.5 install
to switch off the "Add to PATH" option - I assume the new installers
allow that?)