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

Alan Franzoni mailing at franzoni.eu
Thu Nov 18 16:46:23 CST 2010


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.
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


More information about the Mercurial-devel mailing list