Issue 25405: User install of 3.5 removes py.exe from C:\Windows (original) (raw)

Issue25405

Created on 2015-10-14 13:07 by paul.moore, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Messages (5)
msg252990 - (view)	Author: Paul Moore (paul.moore) *	Date: 2015-10-14 13:07
I have had a user install of Python 3.5rc3 for some time on one of my PCs. It also had plenty of other versions on there - 3.4, 3.3, 2.7 and 2.6. The 3.5rc3 install was a user install. I have my Python 3.4 install set up on PATH, and I've configured py.ini to run 3.4 by default. The py launcher was installed in C:\Windows and had version 3.5.123.1013. I can't honestly recall how it got there. I just got round to upgrading to 3.5.0 final. I downloaded the installer and ran it, selecting the default "Upgrade my existing install" option. It ran fine, without elevation, but at the end it reported in the progress area "Previous Version" and requested elevation. When it had finished, py.exe was gone, and I had no filetype associations for .py files. This cannot be correct behaviour. Even for a user install I expect the launcher to work, and filetype associations to exist, by default. Worse still, I then went into Add/Remove programs and selected "Modify" expecting to have to add these back. But the dialog showed them as already selected. When I ran the installer (which in theory should have done nothing, as I had made no changes) it requested elevation and ran, reinstating py.exe into C:\Windows (now at version 3.5.150.1013) and putting back the associations. While I have a complex setup, and expect to do a certain amount of work to get the choices the way I want, the above is utterly confusing - there was no indication that the installer was going to do some of the things it did, and a "no modification" modify *certainly* shouldn't be making changes...
msg252995 - (view)	Author: Steve Dower (steve.dower) *	Date: 2015-10-14 14:32
Part of this will be the upgrade from RC, which will behave differently from the next upgrade to 3.5.1. But I have just made some fixes in how upgrading the launcher is handled, so there's a chance this is already fixed. But I'll test this scenario too. Do you remember whether the launcher was originally installed for all users? At some point I made that the default to better deal with people who have 2.7/3.4 installed (that version of the launcher won't detect 3.5-32).
msg253116 - (view)	Author: Terry J. Reedy (terry.reedy) *	Date: 2015-10-17 03:05
In my view, py.exe is a mess. Steve, I know this is something you just inherited. I have multiple all-user installs. The first problem I have with py.exe is its defaulting to 2.7 instead of latest 3.5, and the impossibility of changing this. The second, given that it does have a default, is its being given all the file associations, so one can only 'open with' 2.7 on the context menu. (I know, pydev discussion is needed.) I have twice changed the default by the cumbersome method given in the Using Python manual, which requires admin privileges, which some people do not have. Yet once again, the default is 2.7. I am not sure whether this reset behavior started with 3.5 or not. I believe not. In any case, the installer does not say whether one should or should not check (or leave checked) "[x] install launcher" when it is already installed. Has it been upgraded ever? Or is the same buggy version just being reinstalled. Paul, it sounds like for your, it did the only the 'delete the old' part of a re-install. Bottom line: it should not be deleted unless re-installed; it should only be re-installed if there is an upgrade; and if it is re-installed, the changed default should not be disturbed. If the latter is not possible with the user change in /Windows, then the method of changing the default should be changed. For instance, "py -default x.y", which would be a good idea anyway.
msg253118 - (view)	Author: Eryk Sun (eryksun) *	Date: 2015-10-17 04:00
Setting a new default for py.exe doesn't require admin privileges. You can use the PY_PYTHON environment variable: C:\>py --version Python 2.7.10 C:\>set PY_PYTHON=3 C:\>py --version Python 3.5.0 which you can easily persist in the registry using setx.exe: C:\>setx PY_PYTHON 3 SUCCESS: Specified value was saved. Check that it was saved: C:\>reg query HKCU\Environment /v PY_PYTHON HKEY_CURRENT_USER\Environment PY_PYTHON REG_SZ 3 You can also use %LOCALAPPDATA%\py.ini to set the default: C:\>py --version Python 2.7.10 C:\>copy con "%localappdata%\py.ini" [defaults] python=3 ^Z 1 file(s) copied. C:\>py --version Python 3.5.0 Note that the environment variable is preferred: C:\Temp>set PY_PYTHON=2 C:\Temp>py --version Python 2.7.10 and an active virtual environment is most preferred: C:\Temp>py -3.5 -m venv testenv C:\Temp>testenv\Scripts\activate.bat (testenv) C:\Temp>py --version Python 3.5.0 (testenv) C:\Temp>py -c "import sys; print(sys.prefix)" C:\Temp\testenv
msg274315 - (view)	Author: Steve Dower (steve.dower) *	Date: 2016-09-03 17:08
I believe this issue is fixed (as of 3.5.1), and I don't specifically know what I'd do to make it more fixed, so I'm closing this. Changing the configuration of the launcher is a separate discussion.