[patch 4/4] This adds support for an [extensions] section to hgrc. This has the form of:

[Chris Mason]

On Friday 12 August 2005 11:41, Bryan O'Sullivan wrote:
> On Fri, 2005-08-12 at 10:43 -0400, Chris Mason wrote:
> > This adds support for an [extensions] section to hgrc.  This has the form
> > of:
> >
> > [extensions]
> > mod=[path]
>
> Nice idea.

Give Matt the credit for the good parts ;)

>
> > Each module must implement a dict called table where the command line
> > options for that module live.
>
> Could this get a more self-explanatory name?  Perhaps something like
> cmdopts?

Sure, I'm not picky.

>
> >   Each module must also implement a reposetup
> > function:
> >
> > def reposetup(ui, repo): pass
>
> It's not clear to me what this is for.
>

The main hg dispatch loop will call any commands the extension provides via 
the table call.  Just like the stuff in commands.py, it will get passed a ui, 
and a repo and any command line args.

But the module might have its own class that needs to be passed for each 
command as well.  In the case of mq, I've got a queue class that has all the 
information about which patches are applied as well as the implementation of 
the commands.

Here's an example of how I use the reposetup function now.

def pop(ui, repo, patch=None, **opts):
    """pop the current patch off the stack"""
    if opts['all']:
        patch = repo.queue.series[0]
    repo.queue.pop(repo, patch, force=opts['force'])

def reposetup(ui, repo):
    repo.queue = queue(ui, repo.opener, repo.join(""))

This is far from perfect since I'm just blinding inserting a new field into 
repo.  There are other options of course, I could make new subclass of the 
repository and put all the mq stuff in there.  But then I would need to 
change other parts of the initialization process in commands.py.

-chris