[Python-Dev] New Windows installer for Python 3.5
Steve.Dower at microsoft.com
Mon Jan 5 02:20:41 CET 2015
Chris Angelico wrote:
> On Mon, Jan 5, 2015 at 9:56 AM, Steve Dower <Steve.Dower at microsoft.com> wrote:
>> (Windows will always put per-user PATH entries at the end). The py.exe
>> launcher handles this best, and the system version will always be found first.
>> As for versions, 3.5 vs 3.6 should be distinguished explicitly ("py -3.5" vs
>> "py -3.6") and 3.5.0 vs 3.5.1 can only be installed at the same time if one is
>> system-wide and the other is per-user. In this case, the per-user one will be
>> used by py.exe, even if it is older than the system-wide one.
> Wait, what?</anna>
> If I'm reading this correctly, PATH is set such that an all-users
> version trumps a self-only version, but when you use the py.exe
> launcher, it's the other way around? That seems extremely confusing.
> But if that's not a deliberate design decision and isn't enforced by
> external code, would it be possible to simply invert that for PATH,
> and have a per-user installation always be found ahead of a
> system-wide one? That would make reasonable sense, if it can be done.
Unfortunately, Windows enforces the PATH ordering. It constructs the PATH from two registry keys, one is the system-wide value (that requires administrative privileges to modify) and it is followed by the user's value (that does not require administrative privileges). This is probably for security reasons and can't be changed.
PATH also suffers from including the most-recently installed Python version first, rather than the most recent version. Basically, py.exe gives the behaviour we want and PATH simply can't do it.
I think this means the best way to make multiple versions work properly is to rename python.exe to python3.5.exe, then install the launcher as python.exe and python3.exe (with some logic to look at its own name) so it can resolve the right version. Maybe we can even extend the launcher to resolve launchers in Scripts (pip.exe, etc.) and have consistent rules there too?
Or perhaps this is more trouble than it's worth, and we should let "py.exe" have a fixed set of rules and let PATH work as people have come to expect. Thoughts?
More information about the Python-Dev