Show the version of Python Launcher for Windows

[oleksis]

Feature or enhancement

Ability to return the version of Python Launcher for Windows running through the argument -V or --version

Pitch

Motivation

Starting with Python 3.11, Python Launcher for Windows has been included

One way to know the version of the py launcher that is running is through the argument '--help' and read the first line of the help content

The following behavior is desired if the argument '--version' is added

➜ $env:PY_PYTHON='3.10'
 
➜ .\PCbuild\amd64\py_d.exe -V
Python Launcher for Windows Version 3.11.1+
Python 3.10.9

➜ .\PCbuild\amd64\py_d.exe --version
Python Launcher for Windows Version 3.11.1+
Python 3.10.9

➜ .\PCbuild\amd64\py_d.exe -V:3.10 -V
Python 3.10.9

➜ .\PCbuild\amd64\py_d.exe -V:3.10 --version
Python 3.10.9

Previous discussion

Linked PRs

• [3.11] Show the Python Launcher version (GH-100829) #100831
• gh-100829: Show the Python Launcher version #100832

[bedevere-bot]

GH-100831 is a backport of this pull request to the 3.11 branch.

[eryksun]

This will break any tool that depends on parsing the known output format of py -V. Maybe introduce a new "--version-launcher" option.

[oleksis]

This will break any tool that depends on parsing the known output format of py -V. Maybe introduce a new "--version-launcher" option.

The new "--version-launcher" option will show the version info and exit or pass extra arguments to the Python py launcher finded ?

[oleksis]

@eryksun thanks for the feedback i make the changes

➜ $env:PY_PYTHON='3.10'
 
➜ .\PCbuild\amd64\py_d.exe -V
Python 3.10.9

➜ .\PCbuild\amd64\py_d.exe -V:3.10 --version
Python 3.10.9

➜ .\PCbuild\amd64\py_d.exe -0v
Python Launcher for Windows Version 3.12.0a3+

➜ .\PCbuild\amd64\py_d.exe --version-launcher
Python Launcher for Windows Version 3.12.0a3+

[eryksun]

You may be better off using SearchPathW() to find the path of "py.exe" and then calling GetFileVersionInfo(). For example, the following uses PyWin32 to inspect the version of the launcher:

>>> py_path = win32api.SearchPath(None, 'py.exe')[0]
>>> info = win32api.GetFileVersionInfo(py_path, '\\')
>>> info['ProductVersionMS'] >> 16
3
>>> info['ProductVersionMS'] & 0xFFFF
11
>>> info['ProductVersionLS'] >> 16
1150
>>> info['ProductVersionLS'] & 0xFFFF
1013

The final value, 1013, is the Python API version, which isn't relevant to the launcher. The third value, 1150, is the micro version number times 1000, plus the release level times 10, plus the release serial number. In this case, the micro version number is 1 (i.e. it's version 3.11.1), the release level is 15, and the release serial is 0. The release levels are defined in Include/patchlevel.h:

cpython/Include/patchlevel.h

Lines 10 to 15 in 951303f

	/* Values for PY_RELEASE_LEVEL */
	#define PY_RELEASE_LEVEL_ALPHA 0xA
	#define PY_RELEASE_LEVEL_BETA 0xB
	#define PY_RELEASE_LEVEL_GAMMA 0xC /* For release candidates */
	#define PY_RELEASE_LEVEL_FINAL 0xF /* Serial should be 0 here */
	/* Higher for patch releases */

[oleksis]

The launcher have the Version defined as string: PY_VERSION

[eryksun]

What I meant is that if you're only concerned with the py launcher on Windows, then using GetFileVersionInfo() will work for all versions of both the old launcher ("launcher.c") and the new launcher ("launcher2.c").

[oleksis]

I make the changes for using the new launcher ("launcher2.c") on Python 3.11+

[jaraco]

I'd recommend not to add variance with the Python launcher for Unix. Ideally these two launchers should converge. Adding changes that apply to only one because they happen to be separate implementations at the moment will only decrease the ability to converge these implementations.

Can you explain more about the motivation for the version? The current launcher already reports the version:

PS C:\Users\jaraco> py -V
Python 3.11.0b3
PS C:\Users\jaraco> py --version
Python 3.11.0b3

How is --version-launcher different from --version?

[oleksis]

How recommended @eryksun adding the output to the version of the Python will break tool depending that behaviour.

Other point is if the argument for Version action will be redirected to the same Version argument option to the Python found

The Python Launcher for Unix until today don't have Version option for the launcher. Here the discussion

Open to the ideas 💡

[brettcannon]

How is --version-launcher different from --version?

The feature request is to know the version of the Launcher itself, not the version of Python that the Launcher will run on your behalf.

But one thing that isn't clear to me is what's the use case for knowing the version of the Launcher (which in the Windows case is the version of Python it was installed with)? And is the use case important enough to complicate the API for the Launcher to add another flag that's explicit to the Launcher and something it has to capture instead of launching Python?

[oleksis]

Thinking in the future, using only the Python Launcher (new version can install other Python) for integration with others tools like Visual Studio Code, DevContainer Features, (python-launcher feature) will easy to check what version of the Python-Launcher is available in the system

[zooba]

I'm not opposed to the change (I'd mildly prefer --launcher-version over --version-launcher), but I'm also not convinced of the use case. Feature detection would be better than checking versions, so if there are features in some versions but not others, and it matters to tools that can't just bring their own copy of the launcher with known feature set, we should add ways to detect those.

[oleksis]

I leave as a reference the fork the Python Launcher for Windows using launcher2.c from CPython and the MSI packages https://github.com/oleksis/pylauncher/releases/tag/latest

[zooba]

Repeating my concerns:

• this is not a reliable way to do feature detection. If we need feature detection, we should add that
• the PR is currently for non-programmatic use (i.e. human readable, not machine readable), so if we want machine readable (again, why?) it needs fixing
• the version is already in the help text
• nobody has provided a likely scenario for needing to read the version number by launching the file (rather than using the version APIs to read the version, or just bringing their own copy of the launcher)

[oleksis]

• nobody has provided a likely scenario for needing to read the version number by launching the file (rather than using the version APIs to read the version, or just bringing their own copy of the launcher)

How I say before in the comment , one scenario is if I want to check the version of the Python Launcher installed in the system without check the --help option and parse the output to find the version (py) of the launcher

Other scenario for example using Devcontainer features . Here a use case but using Python Launcher for Unix

[zooba]

You need to explain why you need to do it "without checking the --help option", especially since the example you posted is using the --help option.

[zooba]

Also, you need a scenario that isn't equally satisfied by "just run the command you want and see if it fails". Since --help or any new option is also going to fail if it's not installed, you have to do this anyway.

[oleksis]

You need to explain why you need to do it "without checking the --help option", especially since the example you posted is using the --help option.

Here was when I see the only way to check the version I using for the setting the feature .

Other side effects is using --help pass that option to the Python ( child process ) returns long output (many lines instead just one line) to parse

[zooba]

using --help pass that option to the Python ( child process ) returns long output (many lines instead just one line) to parse

For a human reading it, I agree. But for programmatically parsing the output, it's still the first line, which is much easier to read than any of the ones that come after it. We also already document the PYLAUNCHER_DRY_RUN environment variable, which will prevent running the child process if there's some reason you really need to do this.

I'm still not convinced we need a third way to get the version of the launcher.

[brettcannon]

I'm not convinced either, so I'm going to close this issue so I haven't seen a core dev be +1 on this idea.