[MERGE][RFC] Enhanced hooks

[Vincent Ladeuil]

>>>>> "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