[PATCH] Fix: prevent gobject._gobject demandimport crash (issue2502)

[Augie Fackler]

On Nov 18, 2010, at 4:46 PM, Alan Franzoni wrote:

> On Wed, Nov 17, 2010 at 8:49 PM, Matt Mackall <mpm at selenic.com> wrote:
>> applications, it's not Mercurial's job to deal with bugs caused by
>> combining it with random libraries. The responsibility falls on the
>> thing that introduces the two: the mercurial_keyring extension.
>
> Good news: mercurial_keyring accepted the patch.
>
> But I took a moment to investigate the issue, by the way. I've not
> been following Mercurial development since long and I can't know
> everything, by the way the demandimport module is designed to improve
> the load time of the mercurial binary, right?
>
> I still think we have an issue. demandimport.enable() changes the
> global __builtin__.__import__ , and replaces it with a version which
> doesn't seem to be fully complaint with the original import.
>
> The root cause of the problem is that, while with the original import
> one can assume that this code will either run with issues or will
> raise an error (if any problem) at the first foo import
>
> import sys
> import foo
> print sys.modules["foo"]
>
> The above is not true when demandimport is enabled. This has nothing
> to do with possible exceptions raised by the module when it's being
> imported, which was what I thought was the problem at the beginning of
> my search.
>
> Of course sys.modules hold all the modules that have been "loaded", so
> if those aren't really loaded maybe it was intentional not to put them
> in sys.modules ? But this is creating issues to unaware developers.
>
> There're some more good news, however:
>
> 1) The venerable "Importing" module from Peak seems to do the very
> same thing as demandimport, but seem to work correctly with
> sys.modules. It does not provide a global import replacement hook, but
> I'll try using it and running Mercurial tests to see what happens.

You'll also need to do some serious performance testing on command  
execution times to see how the speed of Mercurial changes.

> 2) PEP-302 defines a standard way of adding import hooks without
> redefining __builtin__.__import__, maybe it would be easier to use it.
> I'll try hacking into that in the next few days.
>
>
> -- 
> Alan Franzoni
> --
> contact me at public@[mysurname].eu
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel