[PATCH] Add support for external command handlers

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Rusty,

Rusty Russell wrote:
| 	I think you missed my point with this change.

Actually, I agree with most of your points, it's just a matter of
emphasis.  I certainly didn't mean to assert that there's no place for
scripting, or anything like that.

| There are several
| reasons for external commands:

Mostly agreed, but:

| 3) it provides a simple entry point into bzr development,

It's a low barrier to entry, but writing shell scripts is actually
harder than writing python, because you have to support various and
sundry shell interpreters.  The advantage of Python is it's pretty
standardized, but I'd agree that people seem more willing to contribute
Bash scripts than Python scripts.  And yes, I mean 'Bash', not 'POSIX
shell'.

| 4) it allows Martin to see what is missing in bzr, and
| 5) it allows Martin to push off niche features into "contrib".

4 & 5 can also be handled with a plugin system.

| (2) [fill temporary holes] is most pressing for me now: I can
implement "bzr push" *for my
| project* in a one-line shell script ("rsync....").  Implementing that in
| python is just silly, and of no use to Martin.

In fact, my bzr-push script is written in Python, so that it can die if
there are any unknown or modified files in the working tree.  See my
bzrtools announcement for details.

| Similar arguments apply
| to (1): they have to be rewritten anyway to be general, so the initial
| language is unimportant.

If the initial language isn't Python, you can only use bzr commands for
writing your new command, so the initial language can matter.  I'd hate
to see bzr acquire as many only-useful-for-scripting commands as tla
has.  There's a threshold at which the commandline limitations will
force you to write Python anyway, and I don't expect that to change.

| (3) is also important for the vitality of the project, but in the short
| term it's better for Martin to be writing the missing infrastructure
| than arguing over minor patches.  (4) and (5) will become important
| further down the track, a-la netfilter's patch-o-matic.

| Hope that clarifies why I think this is so important,

Certainly, I wouldn't fight to keep it out, but I'm unsure whether it
really is useful, given that people can always create their own bzr-foo
scripts.  Psychologically, being able to add a command to bzr is pretty
cool, and maybe that's reason enough to prefer 'bzr foo' over 'bzr-foo'.

If this is implemented, I think it would make sense to list such
commands under "bzr help".  In order to do that, there needs to be a
standard way to get a one-line description of the command.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCfqGj0F+nu1YWqI0RApQ4AJ95CLjVKOeOi/k8UfrmYt/u5Lm3fQCfQJ3H
NVMK/reHUzibcSlDvQ4+tdw=
=bV8X
-----END PGP SIGNATURE-----