Issue 1504 darcs plugin mechanism

Title darcs plugin mechanism
Priority feature Status given-up
Milestone Resolved in
Superseder Nosy List darcs-devel, dmitry.kurochkin, jaredj, kowey, lelf, mndrix, premchai21, thorkilnaur, tux_rocker
Assigned To
Topics UI

Created on 2009-07-22.12:53:50 by kowey, last changed 2017-07-31.01:30:42 by gh.

msg7984 (view) Author: kowey Date: 2009-07-22.12:53:47
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.
msg7985 (view) Author: kowey Date: 2009-07-22.13:15:46
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:

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.
msg11409 (view) Author: tux_rocker Date: 2010-06-14.06:57:30
Bumping to 2.6
msg15516 (view) Author: simon Date: 2012-04-02.16:09:59
Here's some related code to look at:

1. find MYPROG-* executables in the user's path at startup:

2. include them in --help:

3. call a matched executable if no built-in commands match:


$ 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
msg15524 (view) Author: mndrix Date: 2012-04-03.17:07:34
> 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
msg16877 (view) Author: markstos Date: 2013-06-19.15:35:19
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.
Date User Action Args
2009-07-22 12:53:50koweycreate
2009-07-22 12:54:11koweysetnosy: kowey, simon, thorkilnaur, dmitry.kurochkin
title: darcs plugin mechanism? -> darcs plugin mechanism
2009-07-22 13:15:48koweysetstatus: unread -> unknown
nosy: kowey, simon, thorkilnaur, dmitry.kurochkin
messages: + msg7985
2009-07-22 13:21:02koweysettopic: + ProbablyEasy, UI
nosy: + jaredj
2009-08-18 19:46:58koweylinkissue1495 superseder
2009-08-19 11:06:47koweysetstatus: unknown -> needs-implementation
nosy: kowey, simon, thorkilnaur, jaredj, dmitry.kurochkin
topic: + Target-2.4
2009-08-23 18:07:54koweylinkissue555 superseder
2009-08-25 17:46:22adminsetnosy: + darcs-devel, - simon
2009-08-27 14:30:55adminsetnosy: kowey, darcs-devel, thorkilnaur, jaredj, dmitry.kurochkin
2009-09-14 10:50:15koweysettopic: + Target-2.5, - Target-2.4
nosy: kowey, darcs-devel, thorkilnaur, jaredj, dmitry.kurochkin
2010-06-14 06:57:33tux_rockersettopic: + Target-2.6, - Target-2.5
nosy: + tux_rocker
messages: + msg11409
2010-06-15 21:08:00adminsettopic: - Target-2.6
2010-06-15 21:08:00adminsetmilestone: 2.8.0
2011-06-25 04:47:24premchai21setnosy: + premchai21
2012-02-24 05:34:09mndrixsetnosy: + mndrix
2012-03-07 17:50:56ghsettopic: - ProbablyEasy
2012-03-31 10:45:33mndrixsetnosy: kowey, darcs-devel, thorkilnaur, jaredj, tux_rocker, dmitry.kurochkin, premchai21, mndrix
2012-04-02 16:10:00simonsetmessages: + msg15516
2012-04-03 17:07:35mndrixsetnosy: kowey, darcs-devel, thorkilnaur, jaredj, tux_rocker, dmitry.kurochkin, premchai21, mndrix
messages: + msg15524
milestone: 2.8.0 -> 2.10.0
2013-06-19 15:35:21markstossetmessages: + msg16877
2014-06-27 19:30:05lelfsetnosy: + lelf
2014-11-07 18:42:53ghsetmilestone: 2.10.0 ->
2017-07-31 01:30:42ghsetstatus: needs-implementation -> given-up