[darcs-devel] darcs patch: added postget to prefs (and 2 more)

[David Roundy]

On Thu, Aug 11, 2005 at 09:54:55AM -0700, dagit at eecs.oregonstate.edu wrote:
> Quoting David Roundy <droundy at abridgegame.org>:
> 
> > No, working at a higher level won't address the postget "remote
> > defaults" issue, what it will do is to make your run_posthook function
> > unnecesary, which would mean that adding posthook support to a command
> > will only require that the command add the posthook flag to its list of
> > DarcsOptions, which seems like it would be nice, and the posthook would
> > be guaranteed to always run on command success (i.e. if the command
> > exits with ExitSuccess).  It would mean that we'd have to be careful
> > about when the darcs exits with ExitSuccess... i.e. the question of
> > whether to exit successfully when there are no patches to pull/apply
> > could become significant.
> 
> Could we get around this question by adding a command line switch to
> those commands so that people can specify in defaults what those should
> return when there are no patches?  We could default to exitting
> unsuccessfully when there are no patches, and then let the user override
> this. I think exiting unsuccessfully when there are no patches makes
> sense because when the repo doesn't change, do you really need to run
> your script, right? But at the same time, if you're logging darcs
> activity you may want to record anything and everything.  On the other
> hand, returning the number of patches could be handy too; the problem
> here is that we are no longer consistent with the rest of the unix tools.
> Another solution here is to always run the hook even when there are no
> patches and then pass the number of patches to the script possibly in the
> env.  The problem here is that we are offloading the complexity to the
> scripts, but perhaps this is for the best since each user has a better
> idea how they want to use darcs than we do.

Hmmm.  I think of these options, I'd at least start out with the "passing
the number of patches through the environment" scheme.  This is a nice
feature anyways, since the script might want to customize itself based on
the number of patches.  Then if that seems too burdensome, we could add a
--no-patches-is-failure patch that causes darcs to exit with failure if
there are no patches.  But it seems best to start with the "helpful
anyways" solution.

One could also achieve a similar effect by passing the names of the patches
through the environment, and if that is an empty string, you know there
weren't any patches to be pulled.

> > Actually, I'm thinking that if we implemented posthooks in this manner,
> > we could avoid modifying the commands at all, and add the DarcsOption
> > like we do the --help and --list-options flags in DarcsCommands itself.
> > Then every command would support --posthook, and they'd all behave in
> > the same way.
> >
> > The trick, by the way, would be to use (in consider_running) code
> > something like
> >
> >   do (command_command cmd) (FixFilePath fix_path:specops) extra
> >            `Control.Exception.catch` foo specops
> >      foo (ExitSuccess) specops
> >   where foo (ExitException ExitSuccess) opts = run_posthook opts
> >         foo e = Control.Exception.throwIO e
> >
> > which would mean that if the command either doesn't call exitWith (and
> > just returns) or calls "exitWith ExitSuccess", the posthook will get
> > run.
> 
> I've been keeping myself busy with other projects lately, but this is a
> good idea, maybe I can find time to implement it over the weekend.

That would be great! I sometimes feel like a bit of a leech, sucking
precious developer time out of other projects, or at least hoping to do
so...
-- 
David Roundy
http://www.darcs.net