Add minPositional and maxPositional fields to ArgParser

[nex3]

It's not too difficult to handle argument length validation, but it would be nice if ArgParser had some built-in support for it, especially if it included automatically generating nice error messages.

[munificent]

Yeah, this has been in the back of my mind for a while.

What I'd really like is for ArgParser to have support for parsing arguments and not just options. It should be able to pull out mandatory positional arguments too. I've always had that in mind (which is why the package is "args" and not "options"!) I just haven't gotten there.

Supporting this directly would let args do the validation, and would also let it generate a nice usage line for the command.

[DartBot]

This comment was originally written by @seaneagan

---

Positional arguments are fully supported in:

https://pub.dartlang.org/packages/unscripted

Maybe you can port some of it to args, and then I can use that from unscripted.

It has an internal Positional type which shares some properties with Option, like help, valueHelp, allowed, parser (e.g. int.parse), which can be added to a Usage (unscripted's version of ArgParser) via an addPositional method:

https://github.com/seaneagan/unscripted/blob/master/lib/src/usage.dart#L50

It also has a Rest type which inherits from Positional and defines a "rest parameter" which defines homogeneous trailing positional arguments, and which has a required property which defines whether or not at least one value is required. It can be assigned to a Usage via a rest property since there can only be one of them:

https://github.com/seaneagan/unscripted/blob/master/lib/src/usage.dart#L63

These are all validated upon parsing. They are also used in help text like so:

$ foo.dart --help

Usage:

  foo.dart [<options>] <valueHelp1> <valueHelp2> <restValueHelp>...

    <valueHelp1> <help1>
    <valueHelp2> <help2>
    <restValueHelp> <restHelp>

Options:

  ...

They are also used in unscripted's tab-completion support.

Unscripted does not support optional positionals since dart methods cannot (yet) have both optional named and optional positional arguments, and so supporting optional positionals would mean no "--" options could be added, but presumably args could support it:

parser
    ..addPositional(...)
    ..addPositional(...)
    ..startOptionalPositionals()
    ..addPositional(...)
    ..addPositional(...)
    ..rest = new Rest(...); // or addRest(...)

[DartBot]

This comment was originally written by @seaneagan

---

One clarification, startOptionalPositionals could apply to any addRest call as well, if startOptionalPositionals was called first, then the rest parameter is optional, otherwise required (at least one value must be provided).

Also, in unscripted I'm considering disallowing adding both positionals and sub-commands to the same Usage (ArgParser in args case), since that can be ambiguous. I think right now args assumes anything which matches a sub-command name is the sub-command and not a positional value, but the user might have intended differently. And it would also make the cli invocation hard to read when it includes both positional values and a sub-command name, I don't think I've ever seen it in practice, so shouldn't hurt to disallow it.

[DartBot]

This comment was originally written by @seaneagan

---

Moved to github:

dart-lang/args#12

[DartBot]

This issue has been moved to dart-lang/args#31.