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