I don't know how useful this would be, but maybe it would be good to provide
some mechanism by which people can create darcs commands as plugins.

One way this could look to be able to run "darcs foo" where (if darcs were so
configured), darcs would just hand control off to that plugin

Rough ideas:
- the plugin is a standalone program.  It can be written in any language; it
could even be a shell script for all we care.  For convenience, Haskell hackers
might use the Darcs library to write their plugins, but it's not necessary.

- there would be some very simple easy-to-understand mechanism for darcs to tell
things to the plugins (and back?), say passing JSON objects around.  Things we
could tell the plugin might be: the current repository root, the current path
relative to the repository.

- we would provide a way for the user to write configuration files telling darcs
what plugins to use

- plugins only have to respect a small number of conventions (eg. support a
--help command, tell darcs what your name is).  We leave all command line
parsing up to the plugin.

- Darcs could refuse to run a plugin (sorry, there already is a plugin named "foo")

One thing which we may want to be careful about though is that users be somewhat
aware when they are running a plugin and not darcs proper.  For example, we
could force this by making it something the user would have to install via a
configuration file.

Some potential uses:
 - darcs branch
 - darcs transplant
 - darcs switch (pull/push)
 - darcs show ...

Other benefits might be: giving more incentives to use the Darcs library,
relieving the pressure on us to add commands, being able to get rid of
non-essential commands.  Just seems like the open-endedness of this would be nice.

Also, the configuration mechanism I was thinking of was something like this:
~/.darcs/plugins:

frobnicate /home/me/darcs-frobnicator.py
show index /usr/local/bin/hashed-storage-show-index
show authors /usr/local/bin/darcs-show-authors
delta-debug /usr/local/bin/even-better-than-bisect

(a plugin doesn't have to tell darcs its name after all; the user does that)

Also: the plugin could very well just call darcs do its work, no problems there.

Bumping to 2.6

Here's some related code to look at:

1. find MYPROG-* executables in the user's path at startup:
http://joyful.com/darcsden/simon/hledger/browse/hledger/Hledger/Cli/Opt
ions.hs#L-325

2. include them in --help:
http://joyful.com/darcsden/simon/hledger/browse/hledger/Hledger/Cli/Opt
ions.hs#L-48

3. call a matched executable if no built-in commands match:
http://joyful.com/darcsden/simon/hledger/browse/hledger/Hledger/Cli/Mai
n.hs#L-61

Eg:

$ hledger --help
hledger [COMMAND] ... [OPTIONS]
...
Add-on commands found:
  chart     [-- OPTIONS]   run the hledger-chart program
  interest  [-- OPTIONS]   run the hledger-interest program
  vty       [-- OPTIONS]   run the hledger-vty program
  web       [-- OPTIONS]   run the hledger-web program
...

msg7984:
> there would be some very simple easy-to-understand mechanism for darcs 
to tell things to the plugins (and back?), say passing JSON objects around

To handle communication, I'd like to see darcs set environment variables 
before exec'ing the plugin script.  It's not as flexible as JSON, but 
seems likely to accommodate most use cases

I'm experimenting with some project-specific tools for "darcs-create-
branch", "darcs-switch-branch", and soon "darcs-list-branches".  I 
already use "darcs-changes-files' to list all files related to a 
selection of changes. 

This feature would make our development more pleasant, and could also be 
a great way to test-drive some branch management possibilities for darcs.