Plugin Development Help

[Jelmer Vernooij]

On Wed, Jul 25, 2012 at 01:38:27PM +0000, Alex Lewis wrote:
> Jelmer Vernooij <jelmer <at> samba.org> writes:
> > On Wed, Jul 25, 2012 at 09:31:23AM +0000, Alex Lewis wrote:
> > > Thanks Jelmer!

> > > Jelmer Vernooij <jelmer <at> samba.org> writes:
> > > > That's probably the easiest thing to do. You could also just override
> > > > the implementation of the entire commands, as bzr-loom is doing for
> > > > some commands. That works, but may break if other plugins are trying
> > > > to do the same thing.

> > > If possible I think I'd like to avoid having to copy the implementation of 
> > > cmd_commit into my plugin. It just feels a bit brittle when Bazaar is 
> changed, 
> > > incompatibility with other plugins, etc. I'd like to keep my plugin as 
> simple 
> > > and compatible as possible.
> > I'm not sure if there is an easy way around that. If your plugin is
> > just transforming one option into another, or adding some extra
> > behaviour before or after the command is run, then you don't need to
> > copy the implementation.

> > It seems what you are trying to do requires modification of one of the
> > local variables of cmd_commit.run, so I don't see any other way at the
> > moment to avoid copying the body of cmd_commit.run.

> > Of course, another option would be for the bzr implementation to be
> > extended to allow properties to be passed in.


> I'd be happy to try to make those changes if that were an option? I've had a 
> look at the code and I guess options could be:
> * Add a new parameter to cmd_commit.run revprops=None
>   - Would this be changing the API and thus breaking existing code or would 
> specifying
>     the default value be enough to keep existing code happy?
The options to cmd_commit.run should all be command-line options. An
option though might be to factor out the main code for committing into
another method on cmd_commit and call that from both cmd_commit.run
and from your custom cmd_commit.run. This method could take revprops
and other arguments.

> * Update mutable_tree to provide some way to update revprops from within a 
> start_commit hook.
This would be a good option too.

> * Introduce a new hook somewhere (possibly mutabletree)
Also an option, but I'd rather avoid that if at all possible. We have
plenty of hooks related to commit as it is..

Cheers,

Jelmer