On 10 Jul 2019, at 21:13, 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.
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
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.
-----Original Message----- From: Steve Barnes <GadgetSteve@live.co.uk <mailto:GadgetSteve@live.co.uk>> Sent: Tuesday, July 9, 2019 1:32 AM To: Python-Ideas <python-ideas@python.org <mailto: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 <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/ <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... <https://mail.python.org/archives/list/python-ideas@python.org/message/SI6WMLQ66JSXMWDQZOPY2FWMX4KKAS4S/> Code of Conduct: http://python.org/psf/codeofconduct/ <http://python.org/psf/codeofconduct/>_______________________________________________ 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/ <https://mail.python.org/mailman3/lists/python-ideas.python.org/> Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/EDTOY6... <https://mail.python.org/archives/list/python-ideas@python.org/message/EDTOY6LYY6BTSPMQSIRS6IUTCLZAJIKI/> Code of Conduct: http://python.org/psf/codeofconduct/ <http://python.org/psf/codeofconduct/>