RFC: command composition

[Vincent Ladeuil]

>>>>> "robert" == Robert Collins <robertc at robertcollins.net> writes:

    robert> This is a bit rambly, but I need to get it out of my
    robert> buffers :P.  I'd like to be able to modify the input
    robert> to commands from a plugin, without fully decorating
    robert> the command. Fully decorating is complex because you
    robert> have to keep up with option changes and so on; if I
    robert> could add an option (or options), and when they are
    robert> given be called with the option and arguments (dict,
    robert> list) tuple, then return that to the next handler, I
    robert> could modify the input access to the parsed options
    robert> for a command without having to adjust the plugin
    robert> simply because a new unrelated option was added.

+1 on the idea.

I think it could be achieved by just telling the parser to call a
method with unparsed arguments *before* erroring on them.

The plugin could then define that method and call the error one
if some arguments are left after it has parsed its own options.

That kind of hook could/should also allow sub commands
definitions (the first argument in the unrecognized options being
the sub command name) while keeping common options
handling... common.

    robert> On the down side, this won't give any clue that a
    robert> plugin *will* break when an option changes - e.g. if
    robert> instead of --foo, --bar is needed,

If the plugin should accept the default value for --foo, I see no
solution to this problem...

         Vincent