List-type arg values

[bitprophet]

Strongly related to #9, how to handle list values.

In #9, I assumed they would be contiguous values on the CLI with a separator, e.g. inv mytask --listarg list;val;here.

However, a common pattern for existing arg parsing libs is to give a flag >1 time and have the results tallied into a list, e.g. inv mytask -l list -l val -l here. E.g. this is how argparse/optparse do it, IIRC.

Pros of that latter approach:

• No need to deal with overridden meaning for shell meta-characters (many candidate delimiters have shell meaning.)
  • Counterpoint: commas work pretty good...
• No need to deal with escaping (always a PITA.)
• Minority use case: aping/wrapping pre-existing tools which work this way (e.g. using Invoke as a lightweight argument preprocessor before calling a Java process.)

Cons:

• Harder to implement, requires the parser to be more complicated :(
• Some parsers treat multiple values for the same flag as overrides, so in the above example we'd get -l here "winning" as a string, not list, value. Some users may expect or desire this behavior, e.g. when stitching together args from various "levels" of an invoking program.
• When you are intending to give a list in a single invocation, typing out mytask --listarg a;b;c is much faster than mytask -l a -l b -l c.

Either way:

• Do we perform sub-list transformation, i.e. do we turn mytask --listarg 1,2,3 into a list of ints automatically? Which again ties back into CLI arg typecasting #9.

[sophacles]

I'm strictly opposed to the ; separator. Bash just doesn't like it and quotes start getting nasty (; is assumed to be "end of command" and e.g.:

inv -c gah -r /tmp task1 --arg=foo;bar;baz
this is a task
-bash: bar: command not found
-bash: baz: command not found

)

Other than that, I have a preference towards the mytask -la -lb -l c style.

[drakeguan]

I also prefer the repeating arguments way, or the argparse/optparse way, to handle list. It's more intuitive to work with from viewpoint of commandline. Just wondering how you would like to handle this then.

[bitprophet]

@sophacles Yea that was just a dumb example, if I did go the "sub-parsing" route I'd probably use commas (again) as it's one of the few without common shell meaning.

But it sounds like going for correctness (-l a -l b -l c) over usability (-l a,b,c) may be the right call in this case, esp given how important the parser is as a feature set. We could also add both eventually, though that can and should wait. Thanks for the feedback, guys.

[drakeguan]

@bitprophet Just wondering how would you like to do this. I am willing to provide any help, even though some code snippets as long as you're comfortable with that.

[bitprophet]

@drakeguan I'll take care of it sometime soon, have been on vacation until today.

[drakeguan]

Really excited to know that. Just let us (I believe there are lots developers interested in this feature) know if there is anything need help or discussion, then. Thank you!