Re: [Monotone-devel] New commands (for mtn, in lua)

[Nathaniel Smith]

On Thu, Jul 05, 2007 at 03:09:04PM -0700, William Uther wrote:
>   mtn_automate(...) : This allows any of the automate commands to be  
> called from lua.  The result is returned as a string.
> 
>   alias_command( new_command, old_command) : Add a new command alias  
> to an existing command.

Perhaps we should just be adding these aliases to mtn proper?  I'm not
*super* excited about having a proliferation of aliases that match
every major VCS and having to support them indefinitely, but if
sticking 'blame' and 'praise' in there will make former svn users
happier, *shrug*...

>   register_command(command, abstract, description, lua_function) :  
> Adds a new command to the "user" group of commands.  When the command  
> is called, the associated lua function is executed.  That lua will  
> normally use mtn_automate() calls to do its work.
> 
> I also added automate versions of the following normal commands:  
> push, pull, sync, merge, update and commit.  These are currently not  
> very 'automate' friendly in that they still output everything to  
> standard out.  They work for this purpose though.

The requirement for landing a new automate command in mainline is that
the semantics (what it does) and interface (how you tell it what to do
and how it tells you what its done) must be fully documented and
tested.  Also, we should be willing to keep those semantics and
interface fixed going forward.  Having automate access to the
functionality you mention would indeed be nice; you can decide what
the easiest way to get commands that expose that functionality and
meet the bar for automate inclusion is. 

> I've also added contrib/extra-commands.lua which has the following:

In principle I have no real problem with making monotone more
user-extendable; it can be a great way to prototype new features, see
how useful they are in the wild and whether they're worth folding into
core, etc.

By the time we're actually be *shipping* these in our own source
tarball, though, maybe we should be considering whether we're just
adding these features as extensions because we don't have the communal
will to make the program itself better.  (See also
http://ometer.com/free-software-ui.html)

> function pmup(...)
>     mtn_automate("get_option", "branch")      -- make sure we have a  
> valid workspace
>     mtn_automate("pull")
>     mtn_automate("merge")
>     mtn_automate("update")
> end
> 
> register_command("pup", "Pull, merge and update a workspace",
>       "This command approximates the update command of a centralised  
> revision control system.  " ..
>       "It first contacts the server to gather new revisions, then  
> merges multiple local heads " ..
>       "(if any), and then it updates the workspace.", "pmup")
> 
> function cpm(...)
>     mtn_automate("get_option", "branch")      -- make sure we have a  
> valid workspace
>     mtn_automate("commit")
>     mtn_automate("pull")
>     heads = mtn_automate("heads")
>     words = 0
>     for word in string.gfind(heads, "[^%s]+") do words=words+1 end
>     if words == 1 then
>         mtn_automate("push")
>     else
>         mtn_automate("merge")
>         print("Workspace contents will not be pushed to the server.")
>         print("Please check that merge was successful then push  
> changes.")
>     end
> end
> 
> register_command("cpm", "Commit, pull, merge and push a workspace",
>       "This command approximates the commit command of a centralised  
> revision control system.\n" ..
>       "It first commits your work to the local repository, then  
> contacts the server to gather\n" ..
>       "new revisions.  If there is a single head at this point, then  
> the local changes are pushed\n" ..
>       "to the server.  If there are multiple heads then they are  
> merged, and the user is asked\n" ..
>       "to check things still work before pushing the changes.", "cpm")
> 
> 
> Any thoughts or suggestions?

It looks like in both of the examples, you actually don't want automate
at all -- you're not doing anything programmatic against mtn's data
model, you're just driving the user interface.  If what you want is to
just run user commands, maybe it would be better to be running user
commands than to first move them over to automate (in a sort of
half-done way) and then use them via automate?

You also forgot error checking -- ATM a script called pmu that did
  #!/bin/sh
  mtn "$@" pull && mtn "$@" merge && mtn "$@" update
would actually be superior, because at least it would notice if any of
the commands failed.

Oh, or do mtn_automate("pull") etc. bomb out the mtn process if they
fail?

Another approach to consider might be to have lua commands that were
run with very little mtn infrastructure baked in around them -- like
add a way to use mtn as just a lua interpreter (one that is always
available when mtn is), that has no additional fanciness except maybe
scripts are told where the mtn binary is and what command line options
they might want to pass.  Then scripts could just shell out to mtn
like any other app, and they could use the command line options thing
to pass on -d and friends correctly.  This would make writing such
scripts somewhat more complicated -- you'd need the same shelling-out
support code that other frontends to mtn need -- but that's code that
only needs to be written once and then we have everyone working on
improving one interface, instead of splitting development effort
across two.

> If I was really going to do this right, I think we should replace the  
> entire command/options C++ codebase with a lua version, and allow it  
> all the be scripted/modified.  But that seems like a lot of work.  Is  
> this an acceptable half-way point?

It would be a lot of work, and not work that would give any
incremental improvements while it was ongoing, which means that in
practice it's almost impossible for a FOSS project to accomplish.
(This is probably a good thing, since when people try to fix the world
all at once they always get it wrong anyway.)  The nice thing about
automate is that we can move things over one by one, and the people
moving each command actually want to use it, so they know what sort of
interface will actually work for at least one real-world
application...

-- Nathaniel

-- 
Electrons find their paths in subtle ways.