[PATCH 2 of 2 RFC] dispatch: try and identify third-party extensions as sources of tracebacks

[Idan Kamara]

On Tue, Jul 26, 2011 at 8:31 AM, Brendan Cully <brendan at kublai.com> wrote:
>
> On Monday, 25 July 2011 at 21:55, Augie Fackler wrote:
> > # HG changeset patch
> > # User Augie Fackler <durin42 at gmail.com>
> > # Date 1311622871 18000
> > # Node ID 245f5bbe00788d00ed4e6d6bd27a22c5163365f1
> > # Parent  e59468fa239985828ce199d3ae8cb1768987525c
> > dispatch: try and identify third-party extensions as sources of
tracebacks
> >
> > Extension authors should explicitly declare their supported hg
> > versions and include a buglink attribute in their extension.
> >
> > Packagers should make every effort to ship hg versions from exact
> > tags, or with as few modifications as possible so that the versioning
> > can work appropriately.
>
> Here's a perhaps complementary approach that doesn't require the
> extension to tag itself with version compatibility fields: walk the
> traceback from the inside out, and point the finger at the first frame
> that isn't part of hg core (I don't know a great test for this: I'm
> just looking for extensions with names starting with 'hgext_' for
> now). I don't think it'll catch everything, and it could potentially
> finger the wrong extension, but it'll probably usually work.

Interesting.

Maybe we can use some more Python magic to remember the file/module that
called
extensions.wrapcommand/function, then when we walk the stack trace, look for
extensions.wrap() and pull it back.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20110726/27126f2b/attachment.html>