Fun with loading extensions

Augie Fackler durin42 at gmail.com
Sun Jun 13 22:35:12 CDT 2010


On Jun 11, 2010, at 5:02 PM, Greg Ward wrote:

> I think I have just figured out a very tricky and subtle detail of
> loading extensions.  It boils down to a simple rule: if extension A
> wraps localrepo.X() and extension B subclasses repo.__class__ and
> overrides X(), then you *MUST* load B before A.  If you do not, B's
> override of X() will not be called.
> 
> Here's the catch: the authors of extensions A and B can't do a damn
> thing about this.  Only the end user who is configuring his extensions
> is able to do the right thing, by listing them in the right order in
> his hgrc.  But the end user doesn't have a clue how A or B work.  And
> either A or B could change their implementation from one version to
> the next.
> 
> Hmmmm.  Some possible ways to mitigate this problem:
> 
>  * advise extension authors against the subclassing trick

Ouch. That doesn't feel terribly practical - I'm not seeing an obvious workable way to avoid the subclassing trick with my interop extensions (but I've not been thinking about it for very long, having just seen your message.) Perhaps it's a better option to recommend always use subclassing instead of wrapfunction for repo objects? Does that solve this problem?

>  * demand that extension authors document if their extension must be
> loaded early because it uses the subclassing trick
>  * advise end users to read the source for all the extensions they
> are interested in before configuring them
> 
> ...better ideas?
> 
> Greg
> 
> (Why yes, I am one of those extension authors who has recently
> converted to using the subclassing trick because it avoided another
> conflict.  Aieee!)
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel



More information about the Mercurial-devel mailing list