Python Launcher ignoring config files

[SteveBarnes-BH]

Bug report

Following installing 3.11.0b5 (main, Jul 25 2022, 22:59:14) [MSC v.1932 64 bit (AMD64)] with install launcher for all users py-0 reports that 3.11 is the default py target. Adding a py.ini file with the contents below to both of the following locations:

1. C:\Windows
2. %APPDATA%
   Does not override this - settung PY_PYTHON=3.9 does.
   File content:

[defaults]
python=3.9

Running the older launcher the .ini file settings are honored i.e. py -0 reports 3.9 as the default.

Your environment

Windows 10 - 64bit

• CPython versions tested on:
• Operating system and architecture:
  Windows 10 - 64bit Python: 3.11.0b5 (main, Jul 25 2022, 22:59:14) [MSC v.1932 64 bit (AMD64)] but with multiple other pythons installed.

[eryksun]

The ini file is searched for as "%LOCALAPPDATA%\py.ini" and "%__APPDIR__%\py.ini" (i.e. beside "py.exe")¹. "%APPDATA%\py.ini" has never been checked.

Checking the docs, I see that the "defaults" section is documented to use value names that are "the same as the environment variables without the leading PY_ prefix". There's no "py_" prefix used in the ini file because it configures the default "python", "python3", and "python2" commands, just as in in the "commands" section. This matches the behavior of the old launcher's get_configured_value() function.

The new launcher's checkDefaults() function is designed to use the same names as the environment variables, with the "py_" prefix. This is inconsistent with the old launcher and conceptually inconsistent. It should skip past the "py_" prefix (e.g. &settingName[3]) when calling _readIni().

Footnotes

1. I think the search should be extended to check "%LOCALAPPDATA%\Python\py.ini", "%LOCALAPPDATA%\py.ini", "%ProgramData%\Python\py.ini", and "%__APPDIR__%\py.ini". I dislike using the base %LOCALAPPDATA% directory. Applications are supposed to use a subdirectory named for at least the application, if not nested under the organization name. ↩

[SteveBarnes-BH]

On checking I already had a %LOCALAPPDATA%\py.ini file and it seem to be ignored:

$ type %localappdata%\py.ini
[defaults]
python=3.9
python3=3.9

C:\Users\me\AppData\Roaming
$ py -0p
 -V:3.11 *        C:\Python311\python.exe
 -V:3.10          C:\Python310\python.exe
 -V:3.10-32       C:\Python310-32\python.exe
 -V:3.9           C:\Python39\python.exe
 -V:3.9-32        C:\Python39-32\python.exe
 -V:3.8           C:\Python38\python.exe
 -V:3.8-32        C:\Python38-32\python.exe

C:\Users\me\AppData\Roaming
$ py --version
Python 3.11.0b5

I did find that if I change that specific file to include the prefix:

[defaults]
py_python=3.9
py_python3=3.9

The py stops working altogether - no output from py -0 and no python prompt from py so the file is having some impact. 💩 I also tried both variants with all uppercase for the with no difference of behavior.

[eryksun]

The new launcher's _readIni() function mistakenly returns true (i.e. 1) instead of the string length when the ini file is in the local appdata directory. This in turn causes the wcscpy_s(tag, n + 1, buffer) call in checkDefaults() to invoke the invalid parameter handler, which terminates the process.

When the ini file is beside the launcher instead of in the local appdata directory, _readIni() correctly returns the string length. In this case, py_python=3.9 works for me. Of course, the ini file should instead support python=3.9, which is the initial bug reported here.

[SteveBarnes-BH]

I can verify that if C:\Windows\py.ini is present and contains the values with prefix it is honored - as long at there isn't also a %LOCALAPPDATA%\py.ini also with the prefixed values - in which case nothing is run.

[zooba]

I think the search should be extended to check "%LOCALAPPDATA%\Python\py.ini", "%LOCALAPPDATA%\py.ini", "%ProgramData%\Python\py.ini", and "%__APPDIR__%\py.ini". I dislike using the base %LOCALAPPDATA% directory. Applications are supposed to use a subdirectory named for at least the application, if not nested under the organization name.

I agree, but am filing it under "let's not cause churn right now" as I've discussed elsewhere.

The other two issues are easily fixed. Thanks for catching them!