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 <gadgetst...@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-l...@sdamon.com> > Sent: 10 July 2019 07:23 > To: 'Steve Barnes' <gadgetst...@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. > > > -----Original Message----- > > From: Steve Barnes <gadgetst...@live.co.uk> > > Sent: Tuesday, July 9, 2019 1:32 AM > > To: Python-Ideas <python-ideas@python.org> > > 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 > 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 > > _______________________________________________ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@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/SI6WMLQ66JSXMWDQZOPY2FWMX4KKAS4S/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@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/K5FVV2A5SYTYT4JLLUGS74R7CZNUADAZ/ Code of Conduct: http://python.org/psf/codeofconduct/
