Best way to use a custom ui class in a localrepo?

David Baum dbaum at google.com
Thu Apr 30 12:21:07 CDT 2009


Thanks for the suggestions.  It looks like version 1.3's approach will help
out, but switching to crew isn't really an option (too much production
software relying on this).  So I'll hack something for now and clean it up
after 1.3.
Dave

On Thu, Apr 30, 2009 at 12:11 PM, Matt Mackall <mpm at selenic.com> wrote:

> On Thu, 2009-04-30 at 10:46 -0400, Greg Ward wrote:
> > On Wed, Apr 29, 2009 at 5:26 PM, David Baum <dbaum at google.com> wrote:
> > > even if I create my own
> > > subclass of ui and pass it to hg.repository(), the localrepository
> object
> > > will just go ahead and create its own ui.ui() instance.  I can think of
> > > several workarounds...
> > > 1) Create a subclass of ui and monkey-patch it into the ui module as
> ui...
> > > OriginalUi = ui.ui
> > > class MyUi(OriginalUi):
> > >   ...
> > > ui.ui = MyUi
> > > 2) Let localrepository create a ui.ui(), but then go in and replace it
> > > (repo.ui = MyUi()).  The disadvantage to this is that my custom ui
> won't be
> > > used during the local repository initialization.
> > > 3) Don't bother with a subclass and just monkey-patch the ui methods of
> > > interest (prompt, etc).
> > > To be honest, all of these feel a bit gross.
> >
> > #2 feels like the least gross, but still.  What about
> >
> > 4) provide a patch to localrepo.py that allows you to specify the UI
> > class it should instantiate
>
> In 1.3, repo won't call ui.ui(). It now does self.ui = baseui.copy().
>
> So feel free to do something gross for now. I'd probably go with (3).
>
> --
> http://selenic.com : development and support for Mercurial and Linux
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://selenic.com/pipermail/mercurial/attachments/20090430/48a76366/attachment.htm 


More information about the Mercurial mailing list