https://bugs.freedesktop.org/show_bug.cgi?id=66025
--- Comment #14 from David Bolen <[email protected]> --- Well, expert is a bit strong, but I do at least have some Python/LibO overlap... Michael: The doc reference you made to raising ImportError to *prevent* further processing, but that paragraph also only applies to individual loaders on the meta path, whereas uno is doing a wholesale import replacement (the second paragraph in that section). If it was being implemented now, an import loader as opposed to wholesale __import__ replacement would be cleaner (and avoid uno having to be concerned with default import behavior), but such a change now would require some caution to ensure all existing behavior is maintained, so the cost/benefit tradeoffs are unclear. Tim: At first glance, I'm thinking the issue is not necessarily inside uno per se, but at the very least it's masking the original problem. I'm guessing there is something causing a regular ImportError outside of LibreOffice in your environment for these imports. While uno does do a wholesale import override, the first thing it always does is use the default Python import loader to try to process the import and only does extra processing if that fails. I agree with Michael that your tracebacks (and name/x debug output) don't appear to match the location in your workaround patch. But I don't think that's critical, since from what I can see, it appears uno.py can only reach any of those exceptions if the regular Python import machinery (via the _g_delegatee call to the original __import__ at the top of _uno_import) itself has raised an ImportError. In such a case, the issue is then that any usage of the form "from xxx import yyy" must match a pre-existing imported module, or is assumed to be uno related, with corresponding exceptions. For example: > /opt/libreoffice4.1/program/python Python 3.3.0 (default, Jun 18 2013, 17:24:23) [GCC 4.1.2 20080704 (Red Hat 4.1.2-54)] on linux Type "help", "copyright", "credits" or "license" for more information. (... first without uno ...) >>> import foo Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: No module named 'foo' >>> from foo import bar Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: No module named 'foo' (... next, with uno import override ...) >>> import uno >>> import foo Traceback (most recent call last): File "<stdin>", line 1, in <module> File "./uno.py", line 265, in _uno_import return _g_delegatee( name, *optargs, **kwargs ) ImportError: No module named 'foo' (... fails, but within the uno import function ...) >>> from foo import bar Traceback (most recent call last): File "./uno.py", line 292, in _uno_import d[x] = pyuno.getClass( name + "." + x ) uno.RuntimeException: pyuno.getClass: uno exception foo.bar is unknown During handling of the above exception, another exception occurred: Traceback (most recent call last): File "./uno.py", line 296, in _uno_import d[x] = Enum( name , x ) File "./uno.py", line 123, in __init__ pyuno.checkEnum( self ) uno.RuntimeException: enum foo is unknown During handling of the above exception, another exception occurred: Traceback (most recent call last): File "./uno.py", line 300, in _uno_import d[x] = getConstantByName( name + "." + x ) File "./uno.py", line 48, in getConstantByName return pyuno.getConstantByName( constant ) uno.RuntimeException: foo.bar During handling of the above exception, another exception occurred: Traceback (most recent call last): File "<stdin>", line 1, in <module> File "./uno.py", line 303, in _uno_import raise ImportError( "type "+ name + "." +x + " is unknown" ) ImportError: type foo.bar is unknown >>> Without knowing the original exception, it's hard to say whether uno is involved in the issue. If you were to dump the ImportError exception from the original Python import call, you might get a hint as to the underlying failure, e.g.: *** uno.py.orig 2013-06-18 18:53:44.000000000 -0400 --- uno.py 2013-06-27 16:32:03.000000000 -0400 *************** *** 269,273 **** --- 269,278 ---- if not fromlist: raise + print("--- Python import error --") + import traceback + traceback.print_exc() + print("--- Python import error --") + modnames = name.split( "." ) mod = None d = sys.modules (Tweak as needed to get output in a way you can see it in your environment) Alternatively, making uno's custom import processing more selective could help prevent masking non-uno imports, as in: --- uno.py.orig 2013-06-18 18:53:44.000000000 -0400 +++ uno.py 2013-06-27 17:08:26.000000000 -0400 @@ -266,7 +266,7 @@ except ImportError: # process optargs globals, locals, fromlist = list(optargs)[:3] + [kwargs.get('globals',{}), kwargs.get('locals',{}), kwargs.get('fromlist',[])][len(optargs):] - if not fromlist: + if not (name.startswith('com.sun.star.') and fromlist): raise modnames = name.split( "." ) mod = None I'm reasonably confident all uno imports will start with com.sun.star - certainly enough for this level of testing. There may still be a dependency on some uno behavior that triggers or contributes to the issue, but seeing the underlying ImportError is probably a good next step towards figuring out where to look. -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
