command line support for configuration entries

[Pawel Jasinski]

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.

[Pawel Jasinski]

@mhammond Vinay suggested to get your attention about this one.

[Former user]

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.

[Pawel Jasinski]

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

[Vinay Sajip]

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

[Pawel Jasinski]

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.

[Vinay Sajip]

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.

[Pawel Jasinski]

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

[Vinay Sajip]

Should be fixed in c208472 or later.

[Vinay Sajip]

Fixed Issue #3.

→ <<cset 6adfe59bfcb2>>