Docker: support flag-type container args about girder_worker

[jeffbaumes]

The only thing I don't like is that it requires you to make the id of the input name start with --.

I could see two ways to separate these concerns. One is that you make $flag take two inputs, the input id and the flag name. The other is to move some command argument logic to the input spec, so that there is both an id and an arg variable to help construct the flag (arg could default to '--' + id). I also could see the --input_name=$input{input_name} pattern repeated often, and the arg field with something like $option{input_name} that expands to the that pattern could handle that common case more cleanly.

[jeffbaumes]

As more syntactic sugar, it may be nice to add a single macro $all which expands to $option{id1} $option{id2} ... for all inputs in order. Probably would make sense to use $flag{id} for boolean inputs. There shouldn't be inputs that aren't reflected in the command line arguments to docker, so I expect this would cover many use cases.

[zachmullen]

I like the second proposal; in my first pass at this, I was just using id and name to distinguish between how it is passed on the command line (with dashes) versus how it is displayed to users. But having another, more explicit field for this in the task input would be better, e.g.:

id: "MyFlag"
name: "MyFlag"
flag: "--my-flag"
type: "boolean"
format: "boolean"

and if the flag field is not set, we can fall back to the id. Sound reasonable?

[jeffbaumes]

This is a good solution for flag, but if we ever implement the other syntactic sugar I suggested, it may be good to call the key something more generic (arg or something similar) so other non-boolean inputs could describe themselves as well.

[zachmullen]

Good point, I'll use arg then.