Re: [Monotone-devel] monotone's automation interface

[Nathaniel Smith]

On Thu, Mar 16, 2006 at 08:56:47PM -0600, Glen Ditchfield wrote:
> I had a few thoughts after writing my maildir assistant script.
> 
> * "monotone automate inventory" is a pretty blunt tool for finding missing, 
> unknown, and ignored files, since (in Monotone 0.25) it produces a line for 
> every file in the working copy.  In my case, that's 16,000 lines to sort 
> through when I'm only interested in tracking down roughly a dozen mail files 
> that have been moved, renamed, or deleted.  It would help somewhat if the 
> inventory command took a directory name as an argument, and only printed an 
> inventory of files in that directory; then I could execute "monotone automate 
> inventory Mail", but I would still have 8,500 lines to process.

Good idea -- want to file a bug report?

> * The script executes one "monotone rename" or "monotone drop" command for 
> each missing message.  If "monotone automate" is supposed to be the preferred 
> scripting interface, then there ought to be a way to feed drop and rename 
> commands to "monotone automate stdio".

Good idea -- we extend 'automate' on demand, that being the only known
way to make sensible interfaces.  If you need it, we should consider
adding it :-).

> * I don't know whether the script is portable to Windows, let alone VMS.

A bit annoying, yeah, given the peculiarities in process management on
each platform.  OTOH, pretty much every language has ways to deal with
this, and it only has to be dealt with once in each language, everyone
else can just use a monotone library that hides that stuff.

> So, I started day-dreaming.  What if monotone extended its Lua interpreter 
> with a monotone library?  There could be functions like mtn.rename(path), and 
> iterators like mtn.inventory().  What if the command "monotone mtn-mail" 
> caused monotone to look for a Lua script named "mtn-mail" and execute it with 
> the extended interpreter?

It's possible -- the general idea has come up before.  The advantage
of the automate system is that:
  -- it works for every language; the only other option that comes
     nearly as close is making a C binding, but that doesn't work for
     the shell (and people write shell scripts that do VCS stuff _all
     the time_), and you _have_ to write special bindings to use it in
     any other language.
  -- we don't have to let anyone else into our address space.  It is a
     huge benefit for correctness and such that we can audit all our
     code and change APIs at a whim; preserving this would mean that
     writing an API is... exactly as much work as writing automate.
     In particular, your above two complaints would be exactly as
     likely to apply :-).
  -- it still gives us implementation experience on what an API should
     look like, for when we do get around to writing one.

-- Nathaniel

-- 
"The problem...is that sets have a very limited range of
activities -- they can't carry pianos, for example, nor drink
beer."