Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Launcher add list and list with paths options #74547

Closed
GadgetSteve mannequin opened this issue May 14, 2017 · 14 comments
Closed

Launcher add list and list with paths options #74547

GadgetSteve mannequin opened this issue May 14, 2017 · 14 comments
Labels
3.7 OS-windows type-feature

Comments

@GadgetSteve
Copy link
Mannequin

@GadgetSteve GadgetSteve mannequin commented May 14, 2017

BPO 30362
Nosy @terryjreedy, @pfmoore, @tjguk, @zware, @eryksun, @zooba, @GadgetSteve
PRs
  • #1578
  • Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = None
    closed_at = <Date 2017-06-28.19:25:44.019>
    created_at = <Date 2017-05-14.09:13:17.120>
    labels = ['type-feature', '3.7', 'OS-windows']
    title = 'Launcher add list and list with paths options'
    updated_at = <Date 2017-06-28.19:25:44.017>
    user = 'https://github.com/GadgetSteve'

    bugs.python.org fields:

    activity = <Date 2017-06-28.19:25:44.017>
    actor = 'steve.dower'
    assignee = 'none'
    closed = True
    closed_date = <Date 2017-06-28.19:25:44.019>
    closer = 'steve.dower'
    components = ['Windows']
    creation = <Date 2017-05-14.09:13:17.120>
    creator = 'Steve Barnes'
    dependencies = []
    files = []
    hgrepos = []
    issue_num = 30362
    keywords = []
    message_count = 14.0
    messages = ['293642', '293725', '293749', '293969', '294014', '294033', '294060', '294081', '294099', '294355', '294369', '296069', '297213', '297214']
    nosy_count = 7.0
    nosy_names = ['terry.reedy', 'paul.moore', 'tim.golden', 'zach.ware', 'eryksun', 'steve.dower', 'Steve Barnes']
    pr_nums = ['1578']
    priority = 'normal'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = 'enhancement'
    url = 'https://bugs.python.org/issue30362'
    versions = ['Python 3.7']

    @GadgetSteve
    Copy link
    Mannequin Author

    @GadgetSteve GadgetSteve mannequin commented May 14, 2017

    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.

    @GadgetSteve GadgetSteve mannequin added 3.7 OS-windows type-feature labels May 14, 2017
    @zooba
    Copy link
    Member

    @zooba zooba commented May 15, 2017

    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.

    @GadgetSteve
    Copy link
    Mannequin Author

    @GadgetSteve GadgetSteve mannequin commented May 16, 2017

    @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.

    @terryjreedy
    Copy link
    Member

    @terryjreedy terryjreedy commented May 19, 2017

    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 bpo-30405 (register locally built binaries) more useful.

    @GadgetSteve
    Copy link
    Mannequin Author

    @GadgetSteve GadgetSteve mannequin commented May 20, 2017

    @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.

    @eryksun
    Copy link
    Contributor

    @eryksun eryksun commented May 20, 2017

    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.

    @zooba
    Copy link
    Member

    @zooba zooba commented May 20, 2017

    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.

    @GadgetSteve
    Copy link
    Mannequin Author

    @GadgetSteve GadgetSteve mannequin commented May 21, 2017

    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.

    @pfmoore
    Copy link
    Member

    @pfmoore pfmoore commented May 21, 2017

    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.

    @GadgetSteve
    Copy link
    Mannequin Author

    @GadgetSteve GadgetSteve mannequin commented May 24, 2017

    --list and --list-paths added back in following review by paul.moore.
    The short options -0 & -0p left in as short forms.

    @GadgetSteve
    Copy link
    Mannequin Author

    @GadgetSteve GadgetSteve mannequin commented May 24, 2017

    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.

    @GadgetSteve
    Copy link
    Mannequin Author

    @GadgetSteve GadgetSteve mannequin commented Jun 15, 2017

    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.

    @zooba
    Copy link
    Member

    @zooba zooba commented Jun 28, 2017

    New changeset 5b8f972 by Steve Dower (Steve (Gadget) Barnes) in branch 'master':
    bpo-30362 : Add list options to launcher. (bpo-1578)
    5b8f972

    @zooba
    Copy link
    Member

    @zooba zooba commented Jun 28, 2017

    Thanks, Steve!

    @zooba zooba closed this as completed Jun 28, 2017
    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    3.7 OS-windows type-feature
    Projects
    None yet
    Development

    No branches or pull requests

    4 participants