I ran into this problem too, but not with uno. As a side-effect of z3c.autoinclude a completely unrelated package was imported (quodlibet) which installed a wrapper around __import__ in it's __init__ module to detect import errors on certain modules that had moved.
As soon as __import__ is wrapped (by uno or quodlibet or any other wrapper), the GenericSetup utils._resolveDottedName method will fail for any path passed to it, because of the way it tries to 'detect' an import error within a module.
except ImportError:
# Reraise if the import error was caused inside the imported file
if sys.exc_info()[2].tb_next is not None: raise
del parts_copy[ -1 ]
if not parts_copy: return None
Note that is the traceback of the ImportError has a next frame, it is re-raised. With a dotted name like 'Products.CMFCore.exportimport.cachingpolicymgr.importCachingPolicyManager' the last entry is not a module, so the first time round there will *always* be an ImportError. With a wrapped __import__ function, there will always be a next frame in the traceback.
I won't argue about the rights or wrongs of wrapping the __import__ builtin, but I do think that the resolve method could be rethought to not rely on ImportErrors to detect what part of the path is a module and what part is an object inside a module.
In zope.configuration, it is at least assumed that if there is more than one part in the dotted name (part1.part2) the last part is an object name and not a module. If the same assumption was made in the GenericSetup resolver, this particular interaction with uno and other wrappers would at least go away.
I ran into this problem too, but not with uno. As a side-effect of z3c.autoinclude a completely unrelated package was imported (quodlibet) which installed a wrapper around __import__ in it's __init__ module to detect import errors on certain modules that had moved.
As soon as __import__ is wrapped (by uno or quodlibet or any other wrapper), the GenericSetup utils._ resolveDottedNa me method will fail for any path passed to it, because of the way it tries to 'detect' an import error within a module.
The code in question:
while parts_copy:
try:
module = __import__( '.'.join( parts_copy ) )
break
except ImportError: info()[ 2].tb_next is not None: raise
# Reraise if the import error was caused inside the imported file
if sys.exc_
del parts_copy[ -1 ]
if not parts_copy:
return None
Note that is the traceback of the ImportError has a next frame, it is re-raised. With a dotted name like 'Products. CMFCore. exportimport. cachingpolicymg r.importCaching PolicyManager' the last entry is not a module, so the first time round there will *always* be an ImportError. With a wrapped __import__ function, there will always be a next frame in the traceback.
I won't argue about the rights or wrongs of wrapping the __import__ builtin, but I do think that the resolve method could be rethought to not rely on ImportErrors to detect what part of the path is a module and what part is an object inside a module.
In zope.configuration, it is at least assumed that if there is more than one part in the dotted name (part1.part2) the last part is an object name and not a module. If the same assumption was made in the GenericSetup resolver, this particular interaction with uno and other wrappers would at least go away.