Recommended way for plugin to add an option to an existing command?

Eric Siegerman lists08-bzr at davor.org
Sat Mar 19 16:32:35 UTC 2011


I'm new to plugins and hooks, so forgive me if I'm stating either
the obvious or sheer nonsense :-/

On Sat, 2011-03-19 at 12:13 +0100, vila wrote:
>>>>> Neil Martinsen-Burrell <nmb at wartburg.edu> writes:
>     > What is the recommended way to add an option to an existing
command
>     > from a plugin? [...] I'm not sure what the current state of the
art is.

No idea about the best way to do it, but there's a Command hook
"extend_command" that looks to give you *a* way.  It's documented
as being:
    Called after creating a command object to allow modifications
    such as adding or removing options, docs etc. Called with the
    new bzrlib.commands.Command object.


>     > What I would like to do is define a template LogFormatter.
Ideally, I
>     > would do "bzr log --log-format=template --template-str='{revno}
>     > {author}'".

As a usability enhancement, consider a syntax that does away with
"--template-str" entirely, e.g. something like this (by loose
analogy with revision-spec syntax):
    bzr log '--log-format=template:{revno} {author}'

As a bonus, this makes the problem of adding an option go away,
but that's not the main point: the reason I'm requesting it is
because I'm lazy and don't want to have to type (and remember the
names of) two --long-option='s when one will do.


> Well, in this case I would try to *avoid* adding an option to the
> command but instead make the log formatter get the template from a
> config option.

Being able to specify a format on the command line would be, to
my mind, the most useful thing about this plugin!  I often want
to get info about my branch history in some ad-hoc format -- and
because it's ad-hoc, storing the details in a config file would
be both pointless and very inconvenient.

  - Eric





More information about the bazaar mailing list