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:
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 email@example.com Sent: 10 July 2019 07:23 To: 'Steve Barnes' GadgetSteve@live.co.uk; 'Python-Ideas' < firstname.lastname@example.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.
-----Original Message----- From: Steve Barnes GadgetSteve@live.co.uk Sent: Tuesday, July 9, 2019 1:32 AM To: Python-Ideas email@example.com Subject: [Python-ideas] 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
but the user to be able to specify a specific version even if it is a
The currently py or py -3 would give python 3.7 (if installed) but py -3.8
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.
Python-ideas mailing list -- firstname.lastname@example.org To unsubscribe send an email to email@example.com https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://firstname.lastname@example.org/message/SI6WML... Code of Conduct: http://python.org/psf/codeofconduct/