Attempt to add Plone site causes "ImportError: No module named importCachingPolicyManager" in _uno_import if "python-uno" is installed

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

kleist wrote:
> Public bug reported:
>
> This bug was originally reported in
> http://dev.plone.org/plone/ticket/10693 .
>
> Version 4.0b4, installed from the unified installer, with no products at
> all yet.
>
> When adding the first Plone site, I get:
> {{{
> 2010-06-25 10:33:00 ERROR Zope.SiteErrorLog
> 1277472780.530.230225306014 http://localhost:8080/@@plone-addsite
> Traceback (innermost last):
> Module ZPublisher.Publish, line 127, in publish
> Module ZPublisher.mapply, line 77, in mapply
> Module ZPublisher.Publish, line 47, in call_object
> Module Products.CMFPlone.browser.admin, line 186, in __call__
> Module Products.CMFPlone.factory, line 81, in addPloneSite
> Module Products.GenericSetup.tool, line 330, in
> runAllImportStepsFromProfile
> - __traceback_info__: profile-Products.CMFPlone:plone
> Module Products.GenericSetup.tool, line 1078, in
> _runImportStepsFromContext
> Module Products.GenericSetup.tool, line 252, in getSortedImportSteps
> Module Products.GenericSetup.tool, line 261, in
> getImportStepMetadata
> Module Products.GenericSetup.registry, line 257, in getStepMetadata
> Module Products.GenericSetup.utils, line 105, in _resolveDottedName
> - __traceback_info__:
> Products.CMFCore.exportimport.cachingpolicymgr.importCachingPolicyManager
> Module uno, line 262, in _uno_import
> ImportError: No module named importCachingPolicyManager
> }}}
>
> The only place I know of for uno to get involved is Product.PortalTransforms, but the word_to_html.py code says:
> {{{
> # disable office_uno because it doesn't support multithread yet
> ENABLE_UNO = False
> ...
> try:
> if ENABLE_UNO:
> from office_uno import document
> else:
> raise
> except:
> from office_wvware import document
> }}}
>
> so even that shouldn't cause uno to be loaded. Removing python-uno
> avoids the problem with Plone, but breaks some functionality in
> OpenOffice.

 status invalid

This cannot possibly be a bug in CMF: there is no dependency anywhere
on UNO in the software. The traceback has to be coming from some broken
value in the original poster's Plone profile data.

Tres.
- --
===================================================================
Tres Seaver +1 540-429-0999 <email address hidden>
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkwrbI8ACgkQ+gerLs4ltQ6LUACgmtCuTMkNsteCQRqb/g1V03j4
+IkAoM8gTbYhusrjjua10Q9LJ5mDPxlJ
=NmMB
-----END PGP SIGNATURE-----

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.

The code in question:

    while parts_copy:
        try:
            module = __import__( '.'.join( parts_copy ) )
            break

        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.

This is still not a CMF issue.

Last time I checked GenericSetup was part of CMF. This issue can be handled there still.

If you think that the CMF import detection code can be changed in a
fully-backward-compatible way, while still allowing that broken wrapping
mess, please propose an actual fix as a patch / branch.

Such a fix must not modify the semantics for "sane" installations
(existing tests should pass unchanged), and must add tests which
demonstrate the fix.