[Monotone-devel] Re: Feature request: monotone grep

[Bruce Stephens]

Marcel van der Boom <address@hidden> writes:

> On 8 nov 2005, at 19:34, Bruce Stephens wrote:
>
>>> Perhaps there should be a standard way for monotone to call out to
>>> helper scripts, where `monotone grep', for example calls out to the
>>> script `monotone-grep' -- in /usr/share/monotone/bin or the path if
>>> that fails -- with all the necessary information provided on the
>>> command line and in the environment.
>>
>> That idea came up before, and didn't get much support, IIRC.  I think
>> a problem is that everyone's monotone could be different, so it's
>> difficult to document and support, and there's the potential of
>> clashing command names and things.
>
> I posted that idea a while ago. The most important application for
> such a construct for us is having scripts distributed to the people
> in our project. (like inside the repo, inside MT dir would be
> perfect) So they can be rev controlled and maintained alongside the
> actual project code.

Well, there's no problem in a group of people adopting some suitable
conventions.  For example, you could have a branch "tools" that you
always check out and add to your path, and you could have a
shellscript or something to help automate that.  

That wouldn't affect monotone.  I understood that some people wanted
to alter monotone in such a way that such scripts or programs would be
called by subcommands of monotone.  That seems a sane idea (and it's
one that Mercurial and Bazaar-NG use, I think), although I can see
some downsides.  

Maybe it's easier for a python program, in that it would be most
useful for those subcommands to have quite intimate access to the main
program (including calling environment and things, I guess).  That
suggests Lua might be the way to go, but I don't think monotone
exposes enough to lua for that to be all that useful, currently, and
I'm not sure it should.  

My guess is that it would be better to wait, and maybe after the core
program has settled then it'll be easier to see how to safely expose
suitable functionality to lua functions.

[...]