Specify how flags are parsed

[duglin]

See moby/moby#7396 - I think we need avoid the situation that Docker has right now by saying that we're going to do what getopts does.

ping @mikebrow

[mikebrow]

#dibs

[wking]

On Wed, Dec 09, 2015 at 05:52:49AM -0800, Doug Davis wrote:

See moby/moby#7396

Heh, -ff gobbling too futher arguments is not fun :p.

I think we need avoid the situation that Docker has right now by
saying that we're going to do what getopts does.

I agree that we want runtimes to be a bit better behaved (and if I
were writing a runtime, I'd use getopt_long 1 or some other suitably
robust option parser). But I don't know that we need to specify it in
this minimal command-line API. All of the requirements here use long
options (with the GNU-style ‘--’ prefix for compatibility with
getopt_long, but you could use another parser if you want too, notes
in 9d97d39). If runtimes want to provide short options as well, I'm
all for that, but we don't need to specify them here (we can build
higher-level tooling like test suites that just use the required long
options).

[duglin]

My use of the term "getopts" wasn't meant to limit us to just single dash options, I just meant I wanted something well defined and "normal" :-)

I do actually think we should mandate how options are parsed because if we don't then we'll get inconsistencies and confusion. If we just tried to specify it for just the options we define but then allow some other (weird) parsing scheme for app-specific options then I think we're hurting the UX and our customers. IMO they would want consistency. As long as we don't manadate something bizarre I don't think this will be an issue anyway.

I also think we'll have single-dash options at some point as part of the spec.

[wking]

On Wed, Dec 09, 2015 at 09:43:33AM -0800, Doug Davis wrote:

I do actually think we should mandate how options are parsed because
if we don't then we'll get inconsistencies and confusion.

Folks that want portable (between runtime) options should stick to the
stuff defined in this repository, and we'll test all of that to ensure
consistency. If runtimes want to differentiate themselves by using
different short options or parsing schemes for extensions, that's
between them and their users. I'd certainly recommend they pick
something sane, but I don't see a need to require it before certifying
runtime conformance.

I also think we'll have single-dash options at some point as part of
the spec.

What can you do with single-dash options that you can't do with long
options? Again, we're just looking for the minimum API required for
conformance testing, after which we can leave runtimes to do their own
thing.