Suggestion: Windows launcher default to not using pre-releases by default
Currently the py[w] command will launch the latest python by default however I feel that this discourages the testing of pre-releases & release candidates as once they are installed they will become the default. What I would like is for the default to be the highest version number of a full release but the user to be able to specify a specific version even if it is a pre-release. The currently py or py -3 would give python 3.7 (if installed) but py -3.8 would give the pre-release/release candidate if installed. Any thoughts on whether this would be a good idea - I am quite willing to undertake the changes. Steve Barnes
On Mon, Jul 8, 2019 at 10:39 PM Steve Barnes <GadgetSteve@live.co.uk> wrote:
The problem with this is it would either make the Python launcher have to be updated with every release or it would have to download some data to know what versions are not considered stable. Both of these go against the general design of the launcher as it's meant to not require updating, be future-compatible, and extremely fast. -Brett
On Wed, Jul 10, 2019 at 7:48 AM Brett Cannon <brett@python.org> wrote:
What about flipping that around - when you install, have an option to say "make this the default" (active by default), and if you untick it, it flags the installation as "not the default"? Available only if there's an existing default. ChrisA
On Jul 9, 2019, at 16:30, Chris Angelico <rosuav@gmail.com> wrote:
Assuming that’s doable without the whole updating-the-launcher issue, why not make that checkbox inactive by default for prereleases, and only active by default for final releases? That would do exactly what the OP seems to be asking for, right? Is it possible for the installer to see the sys.version_info.releaselevel of the Python it’s installing? If not, I guess it would require a commit every release cycle to mark the new version as “no longer prerelease, so enable the Windows installer checkbox”, but even that doesn’t seem too bad.
On Tue, Jul 9, 2019 at 8:04 PM MRAB <python@mrabarnett.plus.com> wrote:
When you start Python, it reports its version. How discoverable is that version for the launcher, and for tools in general?
`python -V` will print a simple version string and exit, like this example using an executable compiled from the 3.8 git branch: $ python3.8 -V Python 3.8.0b2+
I have made this suggestion in the past. The response then was that there is no metadata in the windows install that includes if the release is development or stable (that information is not stored in the registry). I was advised to adjust my configuration of the py.exe launcher to set a different default version. I think that's a reasonable stance to take with development versions - they are intended for testing in specialist situations, so you can expect the users to take the extra steps to make sure using them doesn't blow up their world. It still would be nice if the registry details of the install had a bool "stable" field that py.exe could poll. I can't imagine it adds a lot to the release process, or adds significant complexity to the launcher, and that negates the need to update the launcher regularly. pre-release.
The currently py or py -3 would give python 3.7 (if installed) but py -3.8
would
My thought is one of: - if an explicit version is not specified the top (i.e. highest version) candidate at the call time could be timestamp checked and compared with a registry or ini file entry - if the entry for that version is missing or has a different timestamp stored then it could be invoked with --version and the version string parsed for either being \d+\.\d+\.\d+\s or \d+\.\d+\.\d+-?\w+ to generate or set a stable/unstable flag (and the timestamp). This should be minimal overhead and would be transparent to the user. - There could be a --refresh-candidates flag or some such that could run through each of the possible pythons, or a specified one, using the same technique to check stability flags and the results saved in the registry and used - this would be less per run overhead but more manual it could potentially be added to a post install step in the installer at some point. - If a metadata flag for the registry could be decided on and honoured by py & pyw but ignored if missing then a separate utility (possibly pip installed) could be used to set/unset it again using the detect version string mechanism or otherwise. (This could possibly even query an online resource to disable by default unsupported, or known bad if it ever became necessary, versions. Any of these approaches would, I believe, address the need for the maintainers to add metadata to the build, (other than what is already added to adjust the version string), and would be fast & future proof (addressing Ben's concerns). -----Original Message----- From: Alex Walters <tritium-list@sdamon.com> Sent: 10 July 2019 07:23 To: 'Steve Barnes' <GadgetSteve@live.co.uk>; 'Python-Ideas' <python-ideas@python.org> Subject: RE: [Python-ideas] Suggestion: Windows launcher default to not using pre-releases by default I have made this suggestion in the past. The response then was that there is no metadata in the windows install that includes if the release is development or stable (that information is not stored in the registry). I was advised to adjust my configuration of the py.exe launcher to set a different default version. I think that's a reasonable stance to take with development versions - they are intended for testing in specialist situations, so you can expect the users to take the extra steps to make sure using them doesn't blow up their world. It still would be nice if the registry details of the install had a bool "stable" field that py.exe could poll. I can't imagine it adds a lot to the release process, or adds significant complexity to the launcher, and that negates the need to update the launcher regularly. pre-release.
The currently py or py -3 would give python 3.7 (if installed) but py -3.8
would
Based on the various responses I've seen, one thing I want to make very clear is the launcher needs to be *fast*. That means no executing Python code, minimizing stat calls, etc. Also be aware that I'm developing a launcher for UNIX, which puts its own twist on this whole situation as there's no real registry on UNIX. ;) So that means there are limited options for making this too fancy. (The UNIX launcher uses PATH and the file name to determine what versions of Python are installed.) One thing I will say is this issue can be solved manually today: environment variables. If you define PY_PYTHON=3.7 then that will make Python 3.7 the default version to use. Same goes for PY_PYTHON3=3.7 if you're launching with `py -3`. Since this discussion is for people installing betas I would assume those people are also installing new versions of Python, which means you probably only need to update this once every 18 months once you install the newest stable feature release. On Wed, Jul 10, 2019 at 12:13 AM Steve Barnes <GadgetSteve@live.co.uk> wrote:
Brett, Can I suggest that it might be an idea to add the honouring of PY_PYTHON and PY_PYTHON2 environmental variables to the help text. This is the missing piece as far as I am concerned. Steve From: Brett Cannon <brett@python.org> Sent: 10 July 2019 18:41 To: Steve Barnes <GadgetSteve@live.co.uk> Cc: Python-Ideas <python-ideas@python.org> Subject: Re: [Python-ideas] Re: Suggestion: Windows launcher default to not using pre-releases by default Based on the various responses I've seen, one thing I want to make very clear is the launcher needs to be fast. That means no executing Python code, minimizing stat calls, etc. Also be aware that I'm developing a launcher for UNIX, which puts its own twist on this whole situation as there's no real registry on UNIX. ;) So that means there are limited options for making this too fancy. (The UNIX launcher uses PATH and the file name to determine what versions of Python are installed.) One thing I will say is this issue can be solved manually today: environment variables. If you define PY_PYTHON=3.7 then that will make Python 3.7 the default version to use. Same goes for PY_PYTHON3=3.7 if you're launching with `py -3`. Since this discussion is for people installing betas I would assume those people are also installing new versions of Python, which means you probably only need to update this once every 18 months once you install the newest stable feature release. On Wed, Jul 10, 2019 at 12:13 AM Steve Barnes <GadgetSteve@live.co.uk<mailto:GadgetSteve@live.co.uk>> wrote: My thought is one of: - if an explicit version is not specified the top (i.e. highest version) candidate at the call time could be timestamp checked and compared with a registry or ini file entry - if the entry for that version is missing or has a different timestamp stored then it could be invoked with --version and the version string parsed for either being \d+\.\d+\.\d+\s or \d+\.\d+\.\d+-?\w+ to generate or set a stable/unstable flag (and the timestamp). This should be minimal overhead and would be transparent to the user. - There could be a --refresh-candidates flag or some such that could run through each of the possible pythons, or a specified one, using the same technique to check stability flags and the results saved in the registry and used - this would be less per run overhead but more manual it could potentially be added to a post install step in the installer at some point. - If a metadata flag for the registry could be decided on and honoured by py & pyw but ignored if missing then a separate utility (possibly pip installed) could be used to set/unset it again using the detect version string mechanism or otherwise. (This could possibly even query an online resource to disable by default unsupported, or known bad if it ever became necessary, versions. Any of these approaches would, I believe, address the need for the maintainers to add metadata to the build, (other than what is already added to adjust the version string), and would be fast & future proof (addressing Ben's concerns). -----Original Message----- From: Alex Walters <tritium-list@sdamon.com<mailto:tritium-list@sdamon.com>> Sent: 10 July 2019 07:23 To: 'Steve Barnes' <GadgetSteve@live.co.uk<mailto:GadgetSteve@live.co.uk>>; 'Python-Ideas' <python-ideas@python.org<mailto:python-ideas@python.org>> Subject: RE: [Python-ideas] Suggestion: Windows launcher default to not using pre-releases by default I have made this suggestion in the past. The response then was that there is no metadata in the windows install that includes if the release is development or stable (that information is not stored in the registry). I was advised to adjust my configuration of the py.exe launcher to set a different default version. I think that's a reasonable stance to take with development versions - they are intended for testing in specialist situations, so you can expect the users to take the extra steps to make sure using them doesn't blow up their world. It still would be nice if the registry details of the install had a bool "stable" field that py.exe could poll. I can't imagine it adds a lot to the release process, or adds significant complexity to the launcher, and that negates the need to update the launcher regularly. pre-release.
The currently py or py -3 would give python 3.7 (if installed) but py -3.8
would
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org<mailto:python-ideas@python.org> To unsubscribe send an email to python-ideas-leave@python.org<mailto:python-ideas-leave@python.org> https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/SI6WML... Code of Conduct: http://python.org/psf/codeofconduct/
I knew about the py.ini but not the env vars - nice to know. Adding the info the help would have helped me. Also you could show the path of the INI file in the help. I had to write code to find the value of "the directory returned by calling the Windows function SHGetFolderPath with CSIDL_LOCAL_APPDATA" (from https://docs.python.org/3/using/windows.html#customization <fromhttps://docs.python.org/3/using/windows.html#customization>). Far better to put the path in the help. I tend to avoid env vars on windows as its chunky to work with compared to mac or linux. I wonder if it would be useful to be able to have py.exe update the user's py.ini from the command line? py -3.7 --set-default And be able to see what the defaults are? py --show-defaults Barry
On Wed, Jul 10, 2019 at 1:13 PM Steve Barnes <GadgetSteve@live.co.uk> wrote:
I would then open a bug report and if you feel up for it open a PR (the function you want to change is https://github.com/python/cpython/blob/master/PC/launcher.c#L1398). FYI the Python launcher for UNIX already has this in its help output: https://github.com/brettcannon/python-launcher/blob/master/src/HELP.txt.
I'll also mention it's covered in the official docs at https://docs.python.org/3/using/windows.html#launcher. On Wed, Jul 10, 2019 at 2:04 PM Brett Cannon <brett@python.org> wrote:
Issue raised as bpo-37556 & a PR as #14701 Steve Barnes From: Brett Cannon <brett@python.org> Sent: 10 July 2019 22:06 To: Steve Barnes <GadgetSteve@live.co.uk> Cc: Python-Ideas <python-ideas@python.org> Subject: Re: [Python-ideas] Re: Suggestion: Windows launcher default to not using pre-releases by default I'll also mention it's covered in the official docs at https://docs.python.org/3/using/windows.html#launcher. On Wed, Jul 10, 2019 at 2:04 PM Brett Cannon <brett@python.org<mailto:brett@python.org>> wrote: On Wed, Jul 10, 2019 at 1:13 PM Steve Barnes <GadgetSteve@live.co.uk<mailto:GadgetSteve@live.co.uk>> wrote: Brett, Can I suggest that it might be an idea to add the honouring of PY_PYTHON and PY_PYTHON2 environmental variables to the help text. This is the missing piece as far as I am concerned. I would then open a bug report and if you feel up for it open a PR (the function you want to change is https://github.com/python/cpython/blob/master/PC/launcher.c#L1398). FYI the Python launcher for UNIX already has this in its help output: https://github.com/brettcannon/python-launcher/blob/master/src/HELP.txt. Steve From: Brett Cannon <brett@python.org<mailto:brett@python.org>> Sent: 10 July 2019 18:41 To: Steve Barnes <GadgetSteve@live.co.uk<mailto:GadgetSteve@live.co.uk>> Cc: Python-Ideas <python-ideas@python.org<mailto:python-ideas@python.org>> Subject: Re: [Python-ideas] Re: Suggestion: Windows launcher default to not using pre-releases by default Based on the various responses I've seen, one thing I want to make very clear is the launcher needs to be fast. That means no executing Python code, minimizing stat calls, etc. Also be aware that I'm developing a launcher for UNIX, which puts its own twist on this whole situation as there's no real registry on UNIX. ;) So that means there are limited options for making this too fancy. (The UNIX launcher uses PATH and the file name to determine what versions of Python are installed.) One thing I will say is this issue can be solved manually today: environment variables. If you define PY_PYTHON=3.7 then that will make Python 3.7 the default version to use. Same goes for PY_PYTHON3=3.7 if you're launching with `py -3`. Since this discussion is for people installing betas I would assume those people are also installing new versions of Python, which means you probably only need to update this once every 18 months once you install the newest stable feature release. On Wed, Jul 10, 2019 at 12:13 AM Steve Barnes <GadgetSteve@live.co.uk<mailto:GadgetSteve@live.co.uk>> wrote: My thought is one of: - if an explicit version is not specified the top (i.e. highest version) candidate at the call time could be timestamp checked and compared with a registry or ini file entry - if the entry for that version is missing or has a different timestamp stored then it could be invoked with --version and the version string parsed for either being \d+\.\d+\.\d+\s or \d+\.\d+\.\d+-?\w+ to generate or set a stable/unstable flag (and the timestamp). This should be minimal overhead and would be transparent to the user. - There could be a --refresh-candidates flag or some such that could run through each of the possible pythons, or a specified one, using the same technique to check stability flags and the results saved in the registry and used - this would be less per run overhead but more manual it could potentially be added to a post install step in the installer at some point. - If a metadata flag for the registry could be decided on and honoured by py & pyw but ignored if missing then a separate utility (possibly pip installed) could be used to set/unset it again using the detect version string mechanism or otherwise. (This could possibly even query an online resource to disable by default unsupported, or known bad if it ever became necessary, versions. Any of these approaches would, I believe, address the need for the maintainers to add metadata to the build, (other than what is already added to adjust the version string), and would be fast & future proof (addressing Ben's concerns). -----Original Message----- From: Alex Walters <tritium-list@sdamon.com<mailto:tritium-list@sdamon.com>> Sent: 10 July 2019 07:23 To: 'Steve Barnes' <GadgetSteve@live.co.uk<mailto:GadgetSteve@live.co.uk>>; 'Python-Ideas' <python-ideas@python.org<mailto:python-ideas@python.org>> Subject: RE: [Python-ideas] Suggestion: Windows launcher default to not using pre-releases by default I have made this suggestion in the past. The response then was that there is no metadata in the windows install that includes if the release is development or stable (that information is not stored in the registry). I was advised to adjust my configuration of the py.exe launcher to set a different default version. I think that's a reasonable stance to take with development versions - they are intended for testing in specialist situations, so you can expect the users to take the extra steps to make sure using them doesn't blow up their world. It still would be nice if the registry details of the install had a bool "stable" field that py.exe could poll. I can't imagine it adds a lot to the release process, or adds significant complexity to the launcher, and that negates the need to update the launcher regularly. pre-release.
The currently py or py -3 would give python 3.7 (if installed) but py -3.8
would
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org<mailto:python-ideas@python.org> To unsubscribe send an email to python-ideas-leave@python.org<mailto:python-ideas-leave@python.org> https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/SI6WML... Code of Conduct: http://python.org/psf/codeofconduct/
On 2019-07-09 23:23, Alex Walters wrote:
I agree that it seems the real problem here is the lack of a real way to determine if an available version is a real release or a prerelease/beta. Is it not possible to change that, so that it is possible for the launcher to quickly and easily determine the highest release version available? -- Brendan Barnwell "Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail." --author unknown
On 7/10/19, Brendan Barnwell <brenbarn@brenbarn.net> wrote:
In a previous reply, I gave a simple example based on FIELD3 of the file version (or product version) that's embedded in python[w].exe. This doesn't require changes to the registry, and doesn't require running the executable to parse version information from stdout, which would be relatively slow. It will only work for releases that have the version info in the executable. I don't recall when we started adding it, but I know the 2.7 executable doesn't have it.
On 7/9/19, Steve Barnes <GadgetSteve@live.co.uk> wrote:
With the existing launcher, if we install a pre-release candidate, we can set the PY_PYTHON environment variable to make the launcher default to a preferred stable release. To modify the launcher to detect a "final" build, we can check the file version from the PE image's FIXEDFILEINFO [1]. It consists of four 16-bit values: PY_MAJOR_VERSION, PY_MINOR_VERSION, FIELD3, PYTHON_API_VERSION. What we want is FIELD3, which is the upper WORD in the least significant DWORD (i.e. dwFileVersionLS >> 16). FIELD3 is computed as micro * 1000 + levelnum * 10 + serial where levelnum is alpha: 10 beta: 11 candidate: 12 final: 15 and serial is 0-9. The executable is a "final" release if FIELD3 modulo 1000 is at least 150. Here's a quick ctypes example with Python 3.7.3: version = ctypes.WinDLL('version', use_last_error=True) szBlock = version.GetFileVersionInfoSizeW(sys.executable, None) block = (ctypes.c_char * szBlock)() version.GetFileVersionInfoW(sys.executable, 0, szBlock, block) pinfo = ctypes.POINTER(ctypes.c_ulong)() szInfo = ctypes.c_ulong() version.VerQueryValueW(block, '\\', ctypes.byref(pinfo), ctypes.byref(szInfo)) >>> (pinfo[3] >> 16) % 1000 150 >>> sys.version_info sys.version_info(major=3, minor=7, micro=3, releaselevel='final', serial=0) [1]: https://docs.microsoft.com/en-us/windows/win32/api/verrsrc/ns-verrsrc-tagvs_...
On Mon, Jul 8, 2019 at 10:39 PM Steve Barnes <GadgetSteve@live.co.uk> wrote:
The problem with this is it would either make the Python launcher have to be updated with every release or it would have to download some data to know what versions are not considered stable. Both of these go against the general design of the launcher as it's meant to not require updating, be future-compatible, and extremely fast. -Brett
On Wed, Jul 10, 2019 at 7:48 AM Brett Cannon <brett@python.org> wrote:
What about flipping that around - when you install, have an option to say "make this the default" (active by default), and if you untick it, it flags the installation as "not the default"? Available only if there's an existing default. ChrisA
On Jul 9, 2019, at 16:30, Chris Angelico <rosuav@gmail.com> wrote:
Assuming that’s doable without the whole updating-the-launcher issue, why not make that checkbox inactive by default for prereleases, and only active by default for final releases? That would do exactly what the OP seems to be asking for, right? Is it possible for the installer to see the sys.version_info.releaselevel of the Python it’s installing? If not, I guess it would require a commit every release cycle to mark the new version as “no longer prerelease, so enable the Windows installer checkbox”, but even that doesn’t seem too bad.
On Tue, Jul 9, 2019 at 8:04 PM MRAB <python@mrabarnett.plus.com> wrote:
When you start Python, it reports its version. How discoverable is that version for the launcher, and for tools in general?
`python -V` will print a simple version string and exit, like this example using an executable compiled from the 3.8 git branch: $ python3.8 -V Python 3.8.0b2+
I have made this suggestion in the past. The response then was that there is no metadata in the windows install that includes if the release is development or stable (that information is not stored in the registry). I was advised to adjust my configuration of the py.exe launcher to set a different default version. I think that's a reasonable stance to take with development versions - they are intended for testing in specialist situations, so you can expect the users to take the extra steps to make sure using them doesn't blow up their world. It still would be nice if the registry details of the install had a bool "stable" field that py.exe could poll. I can't imagine it adds a lot to the release process, or adds significant complexity to the launcher, and that negates the need to update the launcher regularly. pre-release.
The currently py or py -3 would give python 3.7 (if installed) but py -3.8
would
My thought is one of: - if an explicit version is not specified the top (i.e. highest version) candidate at the call time could be timestamp checked and compared with a registry or ini file entry - if the entry for that version is missing or has a different timestamp stored then it could be invoked with --version and the version string parsed for either being \d+\.\d+\.\d+\s or \d+\.\d+\.\d+-?\w+ to generate or set a stable/unstable flag (and the timestamp). This should be minimal overhead and would be transparent to the user. - There could be a --refresh-candidates flag or some such that could run through each of the possible pythons, or a specified one, using the same technique to check stability flags and the results saved in the registry and used - this would be less per run overhead but more manual it could potentially be added to a post install step in the installer at some point. - If a metadata flag for the registry could be decided on and honoured by py & pyw but ignored if missing then a separate utility (possibly pip installed) could be used to set/unset it again using the detect version string mechanism or otherwise. (This could possibly even query an online resource to disable by default unsupported, or known bad if it ever became necessary, versions. Any of these approaches would, I believe, address the need for the maintainers to add metadata to the build, (other than what is already added to adjust the version string), and would be fast & future proof (addressing Ben's concerns). -----Original Message----- From: Alex Walters <tritium-list@sdamon.com> Sent: 10 July 2019 07:23 To: 'Steve Barnes' <GadgetSteve@live.co.uk>; 'Python-Ideas' <python-ideas@python.org> Subject: RE: [Python-ideas] Suggestion: Windows launcher default to not using pre-releases by default I have made this suggestion in the past. The response then was that there is no metadata in the windows install that includes if the release is development or stable (that information is not stored in the registry). I was advised to adjust my configuration of the py.exe launcher to set a different default version. I think that's a reasonable stance to take with development versions - they are intended for testing in specialist situations, so you can expect the users to take the extra steps to make sure using them doesn't blow up their world. It still would be nice if the registry details of the install had a bool "stable" field that py.exe could poll. I can't imagine it adds a lot to the release process, or adds significant complexity to the launcher, and that negates the need to update the launcher regularly. pre-release.
The currently py or py -3 would give python 3.7 (if installed) but py -3.8
would
Based on the various responses I've seen, one thing I want to make very clear is the launcher needs to be *fast*. That means no executing Python code, minimizing stat calls, etc. Also be aware that I'm developing a launcher for UNIX, which puts its own twist on this whole situation as there's no real registry on UNIX. ;) So that means there are limited options for making this too fancy. (The UNIX launcher uses PATH and the file name to determine what versions of Python are installed.) One thing I will say is this issue can be solved manually today: environment variables. If you define PY_PYTHON=3.7 then that will make Python 3.7 the default version to use. Same goes for PY_PYTHON3=3.7 if you're launching with `py -3`. Since this discussion is for people installing betas I would assume those people are also installing new versions of Python, which means you probably only need to update this once every 18 months once you install the newest stable feature release. On Wed, Jul 10, 2019 at 12:13 AM Steve Barnes <GadgetSteve@live.co.uk> wrote:
Brett, Can I suggest that it might be an idea to add the honouring of PY_PYTHON and PY_PYTHON2 environmental variables to the help text. This is the missing piece as far as I am concerned. Steve From: Brett Cannon <brett@python.org> Sent: 10 July 2019 18:41 To: Steve Barnes <GadgetSteve@live.co.uk> Cc: Python-Ideas <python-ideas@python.org> Subject: Re: [Python-ideas] Re: Suggestion: Windows launcher default to not using pre-releases by default Based on the various responses I've seen, one thing I want to make very clear is the launcher needs to be fast. That means no executing Python code, minimizing stat calls, etc. Also be aware that I'm developing a launcher for UNIX, which puts its own twist on this whole situation as there's no real registry on UNIX. ;) So that means there are limited options for making this too fancy. (The UNIX launcher uses PATH and the file name to determine what versions of Python are installed.) One thing I will say is this issue can be solved manually today: environment variables. If you define PY_PYTHON=3.7 then that will make Python 3.7 the default version to use. Same goes for PY_PYTHON3=3.7 if you're launching with `py -3`. Since this discussion is for people installing betas I would assume those people are also installing new versions of Python, which means you probably only need to update this once every 18 months once you install the newest stable feature release. On Wed, Jul 10, 2019 at 12:13 AM Steve Barnes <GadgetSteve@live.co.uk<mailto:GadgetSteve@live.co.uk>> wrote: My thought is one of: - if an explicit version is not specified the top (i.e. highest version) candidate at the call time could be timestamp checked and compared with a registry or ini file entry - if the entry for that version is missing or has a different timestamp stored then it could be invoked with --version and the version string parsed for either being \d+\.\d+\.\d+\s or \d+\.\d+\.\d+-?\w+ to generate or set a stable/unstable flag (and the timestamp). This should be minimal overhead and would be transparent to the user. - There could be a --refresh-candidates flag or some such that could run through each of the possible pythons, or a specified one, using the same technique to check stability flags and the results saved in the registry and used - this would be less per run overhead but more manual it could potentially be added to a post install step in the installer at some point. - If a metadata flag for the registry could be decided on and honoured by py & pyw but ignored if missing then a separate utility (possibly pip installed) could be used to set/unset it again using the detect version string mechanism or otherwise. (This could possibly even query an online resource to disable by default unsupported, or known bad if it ever became necessary, versions. Any of these approaches would, I believe, address the need for the maintainers to add metadata to the build, (other than what is already added to adjust the version string), and would be fast & future proof (addressing Ben's concerns). -----Original Message----- From: Alex Walters <tritium-list@sdamon.com<mailto:tritium-list@sdamon.com>> Sent: 10 July 2019 07:23 To: 'Steve Barnes' <GadgetSteve@live.co.uk<mailto:GadgetSteve@live.co.uk>>; 'Python-Ideas' <python-ideas@python.org<mailto:python-ideas@python.org>> Subject: RE: [Python-ideas] Suggestion: Windows launcher default to not using pre-releases by default I have made this suggestion in the past. The response then was that there is no metadata in the windows install that includes if the release is development or stable (that information is not stored in the registry). I was advised to adjust my configuration of the py.exe launcher to set a different default version. I think that's a reasonable stance to take with development versions - they are intended for testing in specialist situations, so you can expect the users to take the extra steps to make sure using them doesn't blow up their world. It still would be nice if the registry details of the install had a bool "stable" field that py.exe could poll. I can't imagine it adds a lot to the release process, or adds significant complexity to the launcher, and that negates the need to update the launcher regularly. pre-release.
The currently py or py -3 would give python 3.7 (if installed) but py -3.8
would
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org<mailto:python-ideas@python.org> To unsubscribe send an email to python-ideas-leave@python.org<mailto:python-ideas-leave@python.org> https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/SI6WML... Code of Conduct: http://python.org/psf/codeofconduct/
I knew about the py.ini but not the env vars - nice to know. Adding the info the help would have helped me. Also you could show the path of the INI file in the help. I had to write code to find the value of "the directory returned by calling the Windows function SHGetFolderPath with CSIDL_LOCAL_APPDATA" (from https://docs.python.org/3/using/windows.html#customization <fromhttps://docs.python.org/3/using/windows.html#customization>). Far better to put the path in the help. I tend to avoid env vars on windows as its chunky to work with compared to mac or linux. I wonder if it would be useful to be able to have py.exe update the user's py.ini from the command line? py -3.7 --set-default And be able to see what the defaults are? py --show-defaults Barry
On Wed, Jul 10, 2019 at 1:13 PM Steve Barnes <GadgetSteve@live.co.uk> wrote:
I would then open a bug report and if you feel up for it open a PR (the function you want to change is https://github.com/python/cpython/blob/master/PC/launcher.c#L1398). FYI the Python launcher for UNIX already has this in its help output: https://github.com/brettcannon/python-launcher/blob/master/src/HELP.txt.
I'll also mention it's covered in the official docs at https://docs.python.org/3/using/windows.html#launcher. On Wed, Jul 10, 2019 at 2:04 PM Brett Cannon <brett@python.org> wrote:
Issue raised as bpo-37556 & a PR as #14701 Steve Barnes From: Brett Cannon <brett@python.org> Sent: 10 July 2019 22:06 To: Steve Barnes <GadgetSteve@live.co.uk> Cc: Python-Ideas <python-ideas@python.org> Subject: Re: [Python-ideas] Re: Suggestion: Windows launcher default to not using pre-releases by default I'll also mention it's covered in the official docs at https://docs.python.org/3/using/windows.html#launcher. On Wed, Jul 10, 2019 at 2:04 PM Brett Cannon <brett@python.org<mailto:brett@python.org>> wrote: On Wed, Jul 10, 2019 at 1:13 PM Steve Barnes <GadgetSteve@live.co.uk<mailto:GadgetSteve@live.co.uk>> wrote: Brett, Can I suggest that it might be an idea to add the honouring of PY_PYTHON and PY_PYTHON2 environmental variables to the help text. This is the missing piece as far as I am concerned. I would then open a bug report and if you feel up for it open a PR (the function you want to change is https://github.com/python/cpython/blob/master/PC/launcher.c#L1398). FYI the Python launcher for UNIX already has this in its help output: https://github.com/brettcannon/python-launcher/blob/master/src/HELP.txt. Steve From: Brett Cannon <brett@python.org<mailto:brett@python.org>> Sent: 10 July 2019 18:41 To: Steve Barnes <GadgetSteve@live.co.uk<mailto:GadgetSteve@live.co.uk>> Cc: Python-Ideas <python-ideas@python.org<mailto:python-ideas@python.org>> Subject: Re: [Python-ideas] Re: Suggestion: Windows launcher default to not using pre-releases by default Based on the various responses I've seen, one thing I want to make very clear is the launcher needs to be fast. That means no executing Python code, minimizing stat calls, etc. Also be aware that I'm developing a launcher for UNIX, which puts its own twist on this whole situation as there's no real registry on UNIX. ;) So that means there are limited options for making this too fancy. (The UNIX launcher uses PATH and the file name to determine what versions of Python are installed.) One thing I will say is this issue can be solved manually today: environment variables. If you define PY_PYTHON=3.7 then that will make Python 3.7 the default version to use. Same goes for PY_PYTHON3=3.7 if you're launching with `py -3`. Since this discussion is for people installing betas I would assume those people are also installing new versions of Python, which means you probably only need to update this once every 18 months once you install the newest stable feature release. On Wed, Jul 10, 2019 at 12:13 AM Steve Barnes <GadgetSteve@live.co.uk<mailto:GadgetSteve@live.co.uk>> wrote: My thought is one of: - if an explicit version is not specified the top (i.e. highest version) candidate at the call time could be timestamp checked and compared with a registry or ini file entry - if the entry for that version is missing or has a different timestamp stored then it could be invoked with --version and the version string parsed for either being \d+\.\d+\.\d+\s or \d+\.\d+\.\d+-?\w+ to generate or set a stable/unstable flag (and the timestamp). This should be minimal overhead and would be transparent to the user. - There could be a --refresh-candidates flag or some such that could run through each of the possible pythons, or a specified one, using the same technique to check stability flags and the results saved in the registry and used - this would be less per run overhead but more manual it could potentially be added to a post install step in the installer at some point. - If a metadata flag for the registry could be decided on and honoured by py & pyw but ignored if missing then a separate utility (possibly pip installed) could be used to set/unset it again using the detect version string mechanism or otherwise. (This could possibly even query an online resource to disable by default unsupported, or known bad if it ever became necessary, versions. Any of these approaches would, I believe, address the need for the maintainers to add metadata to the build, (other than what is already added to adjust the version string), and would be fast & future proof (addressing Ben's concerns). -----Original Message----- From: Alex Walters <tritium-list@sdamon.com<mailto:tritium-list@sdamon.com>> Sent: 10 July 2019 07:23 To: 'Steve Barnes' <GadgetSteve@live.co.uk<mailto:GadgetSteve@live.co.uk>>; 'Python-Ideas' <python-ideas@python.org<mailto:python-ideas@python.org>> Subject: RE: [Python-ideas] Suggestion: Windows launcher default to not using pre-releases by default I have made this suggestion in the past. The response then was that there is no metadata in the windows install that includes if the release is development or stable (that information is not stored in the registry). I was advised to adjust my configuration of the py.exe launcher to set a different default version. I think that's a reasonable stance to take with development versions - they are intended for testing in specialist situations, so you can expect the users to take the extra steps to make sure using them doesn't blow up their world. It still would be nice if the registry details of the install had a bool "stable" field that py.exe could poll. I can't imagine it adds a lot to the release process, or adds significant complexity to the launcher, and that negates the need to update the launcher regularly. pre-release.
The currently py or py -3 would give python 3.7 (if installed) but py -3.8
would
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org<mailto:python-ideas@python.org> To unsubscribe send an email to python-ideas-leave@python.org<mailto:python-ideas-leave@python.org> https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/SI6WML... Code of Conduct: http://python.org/psf/codeofconduct/
On 2019-07-09 23:23, Alex Walters wrote:
I agree that it seems the real problem here is the lack of a real way to determine if an available version is a real release or a prerelease/beta. Is it not possible to change that, so that it is possible for the launcher to quickly and easily determine the highest release version available? -- Brendan Barnwell "Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail." --author unknown
On 7/10/19, Brendan Barnwell <brenbarn@brenbarn.net> wrote:
In a previous reply, I gave a simple example based on FIELD3 of the file version (or product version) that's embedded in python[w].exe. This doesn't require changes to the registry, and doesn't require running the executable to parse version information from stdout, which would be relatively slow. It will only work for releases that have the version info in the executable. I don't recall when we started adding it, but I know the 2.7 executable doesn't have it.
On 7/9/19, Steve Barnes <GadgetSteve@live.co.uk> wrote:
With the existing launcher, if we install a pre-release candidate, we can set the PY_PYTHON environment variable to make the launcher default to a preferred stable release. To modify the launcher to detect a "final" build, we can check the file version from the PE image's FIXEDFILEINFO [1]. It consists of four 16-bit values: PY_MAJOR_VERSION, PY_MINOR_VERSION, FIELD3, PYTHON_API_VERSION. What we want is FIELD3, which is the upper WORD in the least significant DWORD (i.e. dwFileVersionLS >> 16). FIELD3 is computed as micro * 1000 + levelnum * 10 + serial where levelnum is alpha: 10 beta: 11 candidate: 12 final: 15 and serial is 0-9. The executable is a "final" release if FIELD3 modulo 1000 is at least 150. Here's a quick ctypes example with Python 3.7.3: version = ctypes.WinDLL('version', use_last_error=True) szBlock = version.GetFileVersionInfoSizeW(sys.executable, None) block = (ctypes.c_char * szBlock)() version.GetFileVersionInfoW(sys.executable, 0, szBlock, block) pinfo = ctypes.POINTER(ctypes.c_ulong)() szInfo = ctypes.c_ulong() version.VerQueryValueW(block, '\\', ctypes.byref(pinfo), ctypes.byref(szInfo)) >>> (pinfo[3] >> 16) % 1000 150 >>> sys.version_info sys.version_info(major=3, minor=7, micro=3, releaselevel='final', serial=0) [1]: https://docs.microsoft.com/en-us/windows/win32/api/verrsrc/ns-verrsrc-tagvs_...
participants (10)
-
Alex Walters -
Andrew Barnert -
Barry Scott -
Brendan Barnwell -
Brett Cannon -
Chris Angelico -
eryk sun -
Jonathan Goble -
MRAB -
Steve Barnes