[MERGE][RFC] Enhanced hooks

[Robert Collins]

On Tue, 2008-02-05 at 11:01 +1000, Ian Clatworthy wrote:
> Robert Collins wrote:
> 
> > This needs discussion, urgently I think. We /had/ hooks like this and
> > decided it was a pretty crappy UI and stopped. Why are we bringing it
> > back ?
> 
> Our current way of configuring hooks leaves a lot to be desired: it
> requires 'writing a plugin'. Other systems are easier and potential
> adopters have rejected Bazaar on this point alone. See
> https://lists.ubuntu.com/archives/bazaar/2007q4/032657.html.


> Following that feedback, I kicked off a discussion thread on this
> topic
> asking people for what they wanted:
> https://lists.ubuntu.com/archives/bazaar/2007q4/035833.html. Shell
> hooks
> was repeated time and time again.


I remember those thread, but I didn't see 'our current system leaves a
lot to be desired' turn up once. I remember our documentation being a
problem, and that for those users they wanted some specific things that
*we didn't even have hooks for* (pre-commit-starting test scripts, and
centralised mail). Its important to take users feedback, but its also
important to design something that works well consistently. The point
about trivial things like 'run a test script before doing anything
related to commit' are totally reasonable, and I support having a shell
hook plugin to answer those needs.

In detail I saw that:
 - some folk want shell scripts (but noone there actually asked for it
for themselves)
 - feature requests for some new hooks
 - smart server to run hooks
 - discussion about the evolution of the API (not all hooks use a Result
object, for hyysterical raisins).

And really, writing a plugin to hook something is as simple as creating
'myhook.py' and dropping it in the search path. Its tiny:
mycommit.py:
------
from bzrlib.branch import Branch

def WeRunThis(local, master, old_revno, old_revid, new_revno,
    new_revid):
    print "Revision %d committed to branch %s" % (new_revno, master)

Branch.hooks.install_hook('post_commit', WeRunThis)
# optional but nice follows
Branch.hooks.name_hook(branch_commit_hook, "WeRunThis")
------

'Easier' is relative obviously I find marshalling arbitrary urls with
problems like user credential hand-offs MUCH HARDER. Lets talk about
specific defects we can look at fixing.

Frankly I find the current way of configuring hooks extremely easy to
use as both a developer and a user. I set a setting in a config file to
configure the hook. I drop the hook script into my plugins dir. Here's
another:
sometimes.py:
------
from bzrlib.branch import Branch

def MightRunThis(local, master, old_revno, old_revid, new_revno,
    new_revid):
    config = master.get_branch_config()
    if config.get_user_option('WeRunThis'):
        print "Revision %d committed to branch %s" % (new_revno, master)

Branch.hooks.install_hook('post_commit', MightRunThis)
# optional but nice follows
Branch.hooks.name_hook(branch_commit_hook, "MightRunThis")
-----

John suggested pattern matching shell scripts, a better approach is to
user the idiom Debian and a growing number of upstream tools have for
many configuration related things - FOO.d where all of the items in the
directory foo.d are executed; and this is very friendly for shell users;
its conceptually similar to the way bzr plugins are loaded (and why they
are so easy to work with). We can definitely do this for shell scripts
if we like (why should there be only one shell script post-commit
called, for instance) - but I /really/ don't think shell script support
belongs in core. It will just be too freaking hard to make it ROCK like
in-process stuff does.

> Jelmer recently announced his shell-hook plugin. He and I both believe
> that the functionality needs to be in the core. The patches submitted
> yesterday add that.
> 
> The question will then arise, "If shell hooks can be configured in a
> flexible way, why can't Python hooks?".

Python hooks already are much more flexible than shell hooks are likely
to ever be (modulo the serious black mark of not working in a
centralised fashion on the smart server).

-Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20080205/0fac5d3c/attachment.pgp