[MERGE][RFC] Enhanced hooks
Vincent Ladeuil
v.ladeuil+lp at free.fr
Tue Feb 5 22:01:37 GMT 2008
>>>>> "Ian" == Ian Clatworthy <ian.clatworthy at internode.on.net> writes:
Ian> Robert Collins wrote:
>> 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).
I prefer organizing hook scripts into directories too.
Hook signatures seems the most blocking problem. I can't imagine
passing more than a list of strings to a shell script and even
there we may hit some shell limits.
That means post_pull and post_push are already excluded, their
signature is a [Pull|Push]Result object...
The server_started signature may be addressed by reverting the
arguments:
def hook(public_url, backing_urls)
instead of
def hook(backing_urls, public_url)
IMHO, this limitation restrict shell hooks use to cases where:
- the script gives back nothing,
- we may even ignore errors (or may be not for pre_commit ?),
- we should define them where we really have no better solution
to address user needs.
>> 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.
I agree with that, bzr commands should be atomic and as such
wrapping them in scripts should address most needs.
The only cases where most users may want a hook is pre_commit or
post_commit ones and mostly because their workflow may be unclear
when migrating from centralized to decentralized.
So may be some patterns should be extracted from existing
plugins like bzr-email and bzr-pqm to make it easier to address
yet-unknown needs.
>> It will just be too freaking hard to make it ROCK like
>> in-process stuff does.
I share that feeling too.
Making different languages communicate efficiently is a damn hard
problem and is generally done to gain either better performances
or more capabilities. Shell can't give us either.
Vincent
More information about the bazaar
mailing list