classification
Title: Launcher add list and list with paths options
Type: enhancement Stage: resolved
Components: Windows Versions: Python 3.7
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: Steve Barnes, eryksun, paul.moore, steve.dower, terry.reedy, tim.golden, zach.ware
Priority: normal Keywords:

Created on 2017-05-14 09:13 by Steve Barnes, last changed 2017-06-28 19:25 by steve.dower. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 1578 merged Steve Barnes, 2017-05-14 13:58
Messages (14)
msg293642 - (view) Author: Steve Barnes (Steve Barnes) * Date: 2017-05-14 09:13
Currently the launcher will give an error message if a matching python is not found when using the -x.y-bits notation on the command line however the user has to know which python(s) they have available.

When some pythons have been installed all user and some specific user only the individual user may well not know which pythons they have available.

I would like to suggest adding to the command line -l and -L options for list and Long list options. Each option would populate the installed_pythons list and then

 -l print the list of usable -x.y-bits options currently available.
 -L print the list with the paths of the executable files.

In either case the launcher should terminate after printing the list.

This would be useful for deciding which python(s) to test with and for producing a list to be able to deploy critical updates to all installed pythons.
msg293725 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2017-05-15 17:08
The problem with taking more command line options is that we prevent real Python from ever using those options (or we end up with obscure rules like the "-3" one).

Perhaps you'd be interested in using/contributing to my pep514tools project: https://github.com/zooba/pep514tools ? Because it doesn't have to imitate python.exe, it can have its own command line options, and I'd be totally happy for the __main__.py to be filled out.
msg293749 - (view) Author: Steve Barnes (Steve Barnes) * Date: 2017-05-16 05:38
@steve.dower I did check and none of the currently supported pythons us -l or -L and have implemented it with -list and -long-list but I do appreciate your point that someone might come up with a use for all of these flags in a future version of python.

How about dropping the short flags, (-l & -L), and making the long flags more launcher specific, i.e. --launcher-list and --launcher-list-paths spring to mind.

I really do think that this change would be really useful, e.g. in the short form to generate a list of installed targets that might all need a specific library updated or to create one venv for each installed target, the long version has already helped me out spotting where a python that I was not expecting had been added to the registry.

I'll also take a look over on pep514tools to see if there is anything I can do to help there.
msg293969 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2017-05-19 19:49
py already has the -number option space.  To avoid conflict, use -0 (zero).  I think only one option is needed -- print 'x.y path' for each binary it can find and run.  'x.y' should be the exact option needed to start the particular binary.

This enhancement would enable IDEs to much more easily offer 'Run with x.y'.  It also would make #30405 (register locally built binaries) more useful.
msg294014 - (view) Author: Steve Barnes (Steve Barnes) * Date: 2017-05-20 06:54
@terry.reedy - Very good points and I like the shortness of -0 note that there is already an accepted change to allow -x.y-64 to specifically require the 64 bit versions so we don't need the complex logic to distinguish cases where -x.y will run 32 bit because there is no 64 bit verses -x.y will run 64 bit and -x.y-32 will run 32 bit so I haven't implemented that complex logic.

I have put a tab between the run flag and the path as I find that is easier to detect than some number of spaces.

Found that I needed to move the test for -0 nearer the top as 0 is a potentially valid version specifier, (isdigit).

Also modified the "not found" message to mention -0 as an option for discovery.
msg294033 - (view) Author: Eryk Sun (eryksun) * Date: 2017-05-20 15:15
I'm -0 on the "-0" option, but I think printing the list of registered Python installations would be useful in the --help text and when the launcher fails to find a requested version.
msg294060 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2017-05-20 23:56
I agree with printing discovered interpreters in help text - not a fan of the -0 option.

IDEs should probably go directly to the registry to discover Python installations (or use pep514tools), since the launcher will only launch a subset of them (i.e. per-user overrides per-machine, non-PythonCore are excluded). Relying on py.exe being available (it's optional), being in a certain location (there are multiple possibilities), and having parseable output (which is a *big* implicit guarantee) doesn't make me comfortable.
msg294081 - (view) Author: Steve Barnes (Steve Barnes) * Date: 2017-05-21 07:00
Latest push still has -0 and -0p options for explicit discovery but also defaults to displaying the list if the requested version is not found. (As well as the default python being marked with a trailing * - I have also removed the less than helpful "default python not found when no pythons were found, (very much a corner case).

I feel that the help text is a little on the long side to include the list as well in response to --help so only added it to match not found use case.

I also feel quite strongly that the option for displaying the discovered paths saves a step or two in locating problem installations.
msg294099 - (view) Author: Paul Moore (paul.moore) * (Python committer) Date: 2017-05-21 10:52
I'm also not a fan of the -0 option. I'm OK with the ability to list available interpreters, but there's nothing about -0 as an option that says to me that's what it's for.

I'm not a huge fan of including the list in the standard help, as py -h already generates the launcher help followed by the Python help and so is pretty verbose.

Maybe just bite the bullet and use "py --list"? It doesn't clash with any existing Python argument, and the core interpreter doesn't typically use long options, so we're probably reasonably safe grabbing --list.
msg294355 - (view) Author: Steve Barnes (Steve Barnes) * Date: 2017-05-24 13:56
--list and --list-paths added back in following review by paul.moore.
The short options -0 & -0p left in as short forms.
msg294369 - (view) Author: Steve Barnes (Steve Barnes) * Date: 2017-05-24 18:11
Note that the -0, --list, -0p & --list-path options will only be invoked if they are the only argument to py.exe this mirrors the original implementation of --help.
msg296069 - (view) Author: Steve Barnes (Steve Barnes) * Date: 2017-06-15 05:56
If this option is added into the py launcher it will make it usable for a multipy script/utility that would call py -0 to get a list of installed pythons and then call it for each of the returned versions with the remaining parameters.

I personally would find this very useful for things like:

    multipy -m pip install --upgrade matplotlib

so as to install upgrades to all of the system pythons.
msg297213 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2017-06-28 19:14
New changeset 5b8f972e093157cc55185841db9ad33fa332a641 by Steve Dower (Steve (Gadget) Barnes) in branch 'master':
bpo-30362 : Add list options to launcher. (#1578)
https://github.com/python/cpython/commit/5b8f972e093157cc55185841db9ad33fa332a641
msg297214 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2017-06-28 19:25
Thanks, Steve!
History
Date User Action Args
2017-06-28 19:25:44steve.dowersetstatus: open -> closed
resolution: fixed
messages: + msg297214

stage: resolved
2017-06-28 19:14:55steve.dowersetmessages: + msg297213
2017-06-15 05:56:23Steve Barnessetmessages: + msg296069
2017-05-24 18:11:11Steve Barnessetmessages: + msg294369
2017-05-24 13:56:31Steve Barnessetmessages: + msg294355
2017-05-21 10:52:54paul.mooresetmessages: + msg294099
2017-05-21 07:00:16Steve Barnessetmessages: + msg294081
2017-05-20 23:56:58steve.dowersetmessages: + msg294060
2017-05-20 15:15:45eryksunsetnosy: + eryksun
messages: + msg294033
2017-05-20 06:54:29Steve Barnessetmessages: + msg294014
2017-05-19 19:49:17terry.reedysetnosy: + terry.reedy
messages: + msg293969
2017-05-16 05:38:12Steve Barnessetmessages: + msg293749
2017-05-15 17:08:32steve.dowersetmessages: + msg293725
2017-05-14 13:58:22Steve Barnessetpull_requests: + pull_request1671
2017-05-14 09:13:17Steve Barnescreate