[MERGE][RFC] Enhanced hooks

[Vincent Ladeuil]

>>>>> "aaron" == Aaron Bentley <aaron at aaronbentley.com> writes:

    aaron> Vincent Ladeuil wrote:
    >>>>>>> "Ian" == Ian Clatworthy <ian.clatworthy at internode.on.net> writes:
    >> 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.

    aaron> You can also pass in environment variables, and this makes it simpler to
    aaron> add new ones and deal with variadic results.

I didn't say there were no ways to allow a powerful API.

My point is that doing more than strings will be a nightmare.

Just look at the smart server. Python both sides, communication
via a socket, a frontier quite similar than crossing languages:
we need to serialize and deserialize.

Or look at the plugins that try to use bzr (the command) instead
of bzrlib, xml-output, tortoisebzr, bzr-eclipse, etc.

The problem is not the hooks by themselves, I'm all *for* hooks
(I'm an emacs user after all). Hooks can *add* their own problems
if they are allowed to introduce conditional behavior though.

<snip/>

    aaron> I disagree.  I want to hook operations, not commands.
    aaron> If I want to hook the fetch operation, then I want to
    aaron> hook push, pull, branch, and anything else that uses
    aaron> it.

Does that mean bzr don't address your needs ?

I mean, as an emacs user, I know and love hookable softwares, but
hooks are there to address needs that the software can't
realistically address. Before using hooks, you can change command
behavior through options or environment variables, hooks are
really the last resort because your need is just so exotic it
will never be taken into account.

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

    aaron> These are good, but IMO they aren't an adequate
    aaron> reaction to the question, "Do you support shell
    aaron> hooks."  The only adequate reaction is "yes."

Amen.

In carefully reviewed places. But not blindly, not everywhere and
with a clearly defined API (not forgetting forward and backward
compatibility issues).

<snip/>

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

    aaron> I don't agree, and I would point out that these
    aaron> scripts can be in any language, not just Bash.

That doesn't matter. What matters is how they communicate. Do you
want to allow the shell scripts to (for example) throw exceptions ?
How ?

What means could be used to communicate between bzr and shell
(lowest component, some of the problems will be easier to solve
for more evolved languages), in increasing order of difficulty:

- procedures with no parameters
- functions with no parameters returning an integer
- parameters:
* string (mostly trivial, but watch for protecting embedded
  separator (space?))
* integers (use strings),
* None (hmm, magic string ?),
* flat lists (watch for the separator (different one)),
* hierarchical lists (watch for the separatorS),
* hashes (separators issues again),
* objects (ha ha, just kidding),
- return value
* integer ok,
* string (hmmm),
* flat list (errr),

And this is just the basic stuff, more sophistication will
require handling of exceptions, locking, reusing already built
objects, etc.

    aaron> An all-Ruby project might find it very convenient to
    aaron> be able to call into their library from a hook.  They
    aaron> might even unit-test it.

Yeah ! Ruby ftw ! :)

I'm sure they will prefer being able to call Ruby from Python
though...( no ! no ! I didn't mean to open another can of
worms !!! Argh, to late ;)

Well, I don't want to sound like I'm *against* hooks (I'm
certainly not), I just wanted to point that it will be hard and
that there will be restrictions compared to python hooks.

       Vincent