[MERGE][RFC] Enhanced hooks

[Ian Clatworthy]

Aaron Bentley wrote:

> This all smacks of absolutism, but I want Bazaar to be a joy to use for
> everyone who uses it.  I think there's a large group of people who don't
> want to use Python for simple hook scripts.  And frankly, that group
> includes me.

I think that captures my feelings on the subject. Bazaar needs to be
friendly to all development teams, not just Python-centric ones. Perl
teams will write their hooks in Perl, Java teams will write their hooks
in Java, Ruby teams will write their hooks in Ruby, etc. In teams with
central repositories where the IT admin team looks after the development
environment, shell or Windows batch files will be the technologies of
choice. Telling users that they only get hooks (or most hooks) if they
use Python will undoubtedly rule Bazaar out of many communities and
organisations. That's sad.

Good usability is about making the common cases easy and the hard cases
possible. As I said earlier, most hooks for most teams (in my
experience) are either "make xxx", "ant xxx" or "send a message to
system yyy". The first two don't require any info passed usually - the
mere existence of the event is enough! The 3rd case only requires simple
strings most of the time. Sure, there are exceptions - we have our
existing hook architecture for those. It's the simple cases where Bazaar
is well below where *I* think it needs to be.

I had a go overnight in implementing Robert's preference for putting
shell hook support in a plugin. Given the lack of consensus, that's the
right place for this feature at this point in time. Longer term, I feel
we need to make external hooks a core feature so users can rely on their
signatures (which would be in the main documentation) and count on them
being there.

I'd /really/ like a small change to the core to make the plugin simpler
and more efficient, namely changing the lookup (not registration) of
hooks to be via the object, not the Branch.hooks or SmartTCPServer.hooks
singletons. So

  for hook in Branch.hooks['post_uncommit']:

would become

  for hook in branch.iter_hooks('post_uncommit'):

for example. If that sounds ok, I'll put up a small patch for that
change. If it doesn't, then shell hooks beyond Jelmer's plugin will need
to wait a while - other priorities have taken over for me.

Ian C.