1. Vinay Sajip
  2. pylauncher
  3. Issues
Issue #3 resolved

command line support for configuration entries

Pawel Jasinski
created an issue

at the moment use of a configuration entries require custom shebang. There is no way to select config entry from command line against a script containing generic shebang or not containing a shebang at all. We propose to extend command line parameter as described here: https://ironpython.codeplex.com/workitem/35064 item 1.

Comments (9)

  1. Mark Hammond

    For (1) I guess I don't see the use-case for this. Wouldn't it be quite trivial to write a python program that found a command-line in a .ini file and executed it? I don't think the launcher should become a general-purpose kitchen-sink tool and should remain focused on the original motivation for it being created, especially when an alternative pure-python implementation seems quite trivial.

    I don't understand the description of (2), but you can expect the same response from me if it is trying to add new functionality rather than enhancing the existing functionality.

  2. Pawel Jasinski reporter

    Mark, PEP 397 says:

    The launcher will be capable of supporting implementations other than
    CPython, such as jython and IronPython, but given both the absence of
    common links on Unix (such as "/usr/bin/jython") and the inability for the
    launcher to automatically locate the installation location of these
    implementations on Windows, the launcher will support this via
    customization options.  Scripts taking advantage of this will not be
    portable (as these customization options must be set to reflect the
    configuration of the machine on which the launcher is running) but this
    ability is nonetheless considered worthwhile.
    

    All we are postulating is having the same level of functionality for IronPython and Jython as it is now implemented for cpython. At the moment you can select version of cpython from command line, but you can not select IronPython nor Jython.

    For the "pure-python" implementation, I am against it. Ironpython and Jython have higher resource footprint and startup time than cpython. Having another process to do, what can be accomplished in trivial C is overkill. Second reason, the "trivial script" would have to be tested with any cpython, IronPython, Jython and very likely individually tuned to each alternative python implementation.

    I will open separate issue for number #2

  3. Vinay Sajip repo owner

    But the intent of the launcher is to support shebang lines, and not primarily to support py -xxx invocation. While py -xxx invocation is useful for testing and for other limited scenarios, that's not really what it's primarily there for. And the other implementations are supported with the current implementation, through customised commands.

    If you write a script for IronPython, simply stick a shebang pointing to the appropriate implementation and the script should be run, by the current launcher, without even having to specify anything in an ini file (tell me if that's not the case). Why should the runner of a script need to know which interpreter to invoke it with? They don't, on POSIX, since the shebang line and shell take care of it. And likewise, on Windows, with the launcher installed (assuming the appropriate file types are associated with it).

  4. Pawel Jasinski reporter

    While py -xxx invocation is useful for testing and for other limited scenarios, that's not really what it's primarily there for.

    Testing is the use case.

    If you write a script for IronPython, simply stick a shebang pointing to the appropriate implementation and the script should be run, by the current launcher, without even having to specify anything in an ini file (tell me if that's not the case).

    I have already created a separate issue to address detecting of IronPython installations.

    c:\cygwin64\home\rejap\bitbucket\pylauncher>001-v3.py
    launcher build: 32bit
    launcher executable: Console
    File 'C:\Users\rejap\AppData\Local\py.ini' non-existent
    File 'C:\Windows\py.ini' non-existent
    Called with command line: "C:\cygwin64\home\rejap\bitbucket\pylauncher\001-v3.py"
    maybe_handle_shebang: read 49 bytes
    maybe_handle_shebang: BOM not found, using UTF-8
    parse_shebang: found command: ipy
    run_child: about to run 'ipy "C:\cygwin64\home\rejap\bitbucket\pylauncher\001-v3.py" '
    Unable to create process using 'ipy "C:\cygwin64\home\rejap\bitbucket\pylauncher\001-v3.py" '
    
    c:\cygwin64\home\rejap\bitbucket\pylauncher>cat 001-v3.py
    #! ipy
    import sys
    sys.stdout.write(sys.version)
    

    Why should the runner of a script need to know which interpreter to invoke it with?

    User who is interested in running a script doesn't care, except: she would like to see what is faster, force 32bit version, or perhaps avoid a bug. Any use case which put the option there for cpython applies.

    The maintainer of a package which targets different implementation would be here a target audience.

    I have already made a PR, so you can asses the scope of the changes involved. I can understand that you are not willing to support it. If this is the case, it is ok to close the issue.

  5. Vinay Sajip repo owner

    I can understand that you are not willing to support it.

    Still thinking about it, but I'm not sure I understand yet the scope of the problem you're trying to solve. Current functionality supports multiple generic interpreters in shebang lines without special-casing anything (I'm not considering the CPython support to be a special case, as the impetus for the launcher development came from CPython development).

    Bear in mind that the main beneficiaries of the launcher are intended to be end-users rather than developers (I well know that developers are end-users too, but they have plenty of options for streamlining their workflow.) Currently, the possibility exists to support IronPython and Jython using shebangs (which could be inserted by an installer into any script which installs an IronPython or Jython application).

    Currently, developers / power users are supported through the .ini file, and ISTM they would certainly know about how to set up their .ini files with customised commands for specific IronPython or Jython interpreters. So is your proposal just about making life that little bit easier for those developers who would rather type py -ipy rather than setting up .ini files with customised commands for IronPython?

    It might be an idea for you to go ahead and implement your changes in your repo, and if they are sufficiently generic for multiple implementations (e.g. across IronPython, Jython, PyPy) we could certainly look at how you've implemented things, see what the maintenance and other trade-offs would be in merging your changes. I'm not opposed to making changes in principle, but the devil is in the details.

    By the way, the changes in the tests that you've suggested (making the tests less tied to specific implementation quirks) aren't controversial, and I will probably incorporate them. Thanks for the feedback you've given.

  6. Pawel Jasinski reporter

    So is your proposal just about making life that little bit easier for those developers who would rather type py -ipy rather than setting up .ini files with customised commands for IronPython?

    yes, but not entire statement is true

    EDIT:

    yes: Making life easier for those developers who would type py -ipy

    no: The customized commands are obligatory anyway.

    It might be an idea for you to go ahead and implement your changes in your repo

    I did it. https://bitbucket.org/vinay.sajip/pylauncher/pull-request/3/name-of-the-configuration-entry-can-be/diff

  7. Log in to comment