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

[William Uther]

On 04/09/2007, at 6:45 PM, Nathaniel Smith wrote:

> 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*...

Hrm....

I can see the support issue here.  When this came up previously the  
point
was raised that aliases can be added through scripting anyway.  This  
seems
cleaner.  I don't like overly cluttered interfaces, but if the  
flexibility
can be introduced in such a way that it doesn't affect those who  
don't use
it, then it is usually ok.

> >   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.

The documentation is not great.  I have already merged with trunk.

Would you like me to disapprove?

The netsync operations still output their ticker to stdio.  You can  
turn it off with
the normal --ticker option.  There isn't much other interface there.

The other commands, update and commit, do have defined interfaces.   
I'm not sure that
they're the best interfaces yet, and they are only defined in

> > 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.

That was my main aim.

> 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)

How can you see how useful something is in the wild without shipping it?

I also think the monotone interface needs work.  I don't want to get  
into
a big argument about it though.  I'd rather propose solutions.

However, I don't claim to be able to get it right first time either.   
I want
an easy way to try a bunch of commands and see which work for me over  
time.
It is an easy way to prototype.

My current set of commands is here:

http://www.cse.unsw.edu.au/~willu/monotone-patches/mtnrc

Note that I'm using alias_command for more than just blame and  
praise.  It also
allows you to name your commands properly and add short aliases just  
like a C++
command.

Also note that I have error checking in there now.  I just haven't  
had time to
commit this yet.

> 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.

Not entirely true.  The remote_commit command gathers the number of  
heads
and outputs a warning if there is more than one.  It asks the user to
merge and check that the merged revision is ok before pushing.

> 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?

There had been requests on the mailing list for a more complete  
automate set.
I was also planning to add "add" and "drop", etc, but I haven't had  
time.

> You also forgot error checking

It is in the latest version of those functions.  In some cases the  
error is ignored, and in others it isn't.

> 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.

That is possible.  I didn't consider that.  Would you prefer that
solution?  I don't think it is better than what is there currently.

The bottom line here: I've become pretty busy lately.  I don't have time
to fine-tune this right now.  If there are parts of this that are a  
problem
merged into trunk, then I apologise - feel free to revert them.

Be well,

Will        :-}