See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725491: --- snip --- In line 335 of uno.py, exception ImportError() use the method .with_traceback() which is not available in Python2.x but only in Python3.x. This lead to an AttributeError() exception and line 338 will never be reached to raise the correct exception ImportError(). Removing the ".with_traceback..." part solve the problem. --- snip --- Diffing in git it was introduced between 4.1.0 and 4.1.1, specially with commit52a533cc31f630ad482fe0fde8d925b459c787bf: commit 52a533cc31f630ad482fe0fde8d925b459c787bf Author: David Bolen <db3l.net@gmail.com> Date: Mon Jul 29 12:44:26 2013 +0200 fdo#66025: Improve accuracy of ImportError traceback and message The ImportError raised on an import failure with the uno module loaded now includes a complete traceback and the original Python exception message text, combined with the most relevant (nearest to failure if imports are nested) uno lookup that also failed. Cherry-picked from 948b6ea02ea9de7fb4e1e2baf95ecae3ba1cd54e plus previous patches leading up to that, 7fd81244c21ad54a8b9766902fd7c34e8055b165 "fdo#66 Improve ImportError raised from _uno_import," 329125abb63061214897e4f215d41cfa4b13b4b0 "fdo#66025: Minor clean-up of previ patch," and fbe28de6fbfdce41544e4e93168d32661add8285 "fdo#66025: Simplify ne ImportError logic." Change-Id: I8c22f22c2d96bdd7fb99a87273ba574e22a86923 Signed-off-by: Stephan Bergmann <sbergman@redhat.com>
CC'ing both...
I'm hesitant to consider this a bug as this patch was only intended for LO versions using Python 3, but if Debian or other distributions are still continuing to build LO 4.1+ UNO modules against Python 2, then yes, it's certainly an issue. In that case, I'm also not entirely sure this will turn out to be the only Python 3-ism at this point in the code base. In terms of background, this commit was to resolve bug 66025, where import failures under Python 3 from any package once LO's UNO module was loaded (regardless of whether the import was related to LO or not) had become extremely difficult to identify the root cause. Two thoughts - first, as indicated in the Debian bug, removing the with_traceback method call will be Python 2 compatible - but defeats the fix under Python 3. So not a good general purpose change, but it could be a local distribution patch when building a Python 2 UNO module. Though pushing the issue downstream feels wrong if there are likely to be other distributions besides Debian building Python 2 versions. Alternatively, runtime version checking could be added for separate Python 2 and 3 code paths (I don't see a way to have a single path that works well under Python 3 while simultaneously supporting 2). I can certainly produce a patch, but while likely modest, I don't currently have an LO build environment to verify against Python 2. Is there any chance you might be able to assist me with a quick sanity check of a patch under Python 2? If not, I suppose since it already fails under Python 2, it's not like I could make it much worse.
> I'm hesitant to consider this a bug as this patch was only intended for LO > versions using Python 3, but if Debian or other distributions are still > continuing to build LO 4.1+ UNO modules against Python 2, then yes, it's When LO 4.0 was released it explicitely was said that python2 was still supported "for a few releases", too, if people need it. "A few releases" of course is totally unclear - but the problem is that there's still loads of stuff out in the wild using pyUNO NOT (or Status unknown) ported. Even the most-used of it (unoconv) needed a patch from git (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707337) "python-openoffice" got fixed by removing it (;-)) and thus we still have #707338 [w|u| ] [bibus] please support python3 (and python3-uno) #707339 [w|u| ] [ooo2dbk] please support python3 (and python3-uno) #707340 [w|u| ] [docvert-libreoffice] please support python3 (and python3-uno) #707341 [w|u| ] [gnumed-client] please support python3 (and python3-uno) #707342 [w|u| ] [src:sqlkit] please support python3 (and python3-uno) reported by me in the Debian BTS... Otherwise I'd have stopped building python-uno, yes... I _know_ they are not working with stock LO 4.1+ and need to adapt, but... > certainly an issue. In that case, I'm also not entirely sure this will turn > out to be the only Python 3-ism at this point in the code base. so far it is. > Two thoughts - first, as indicated in the Debian bug, removing the > with_traceback method call will be Python 2 compatible - but defeats the fix > under Python 3. So not a good general purpose change, but it could be a > local distribution patch when building a Python 2 UNO module. Though pushing Yeah, that's I am doing now (see http://anonscm.debian.org/gitweb/?p=pkg-openoffice/libreoffice.git;a=commitdiff;h=94dd0058eeb361cc16f824076da08062aebffec7;hp=eff512e1204010d9b0fb474d4d4bf12ea43928d9#patch4) > Alternatively, runtime version checking could be added for separate Python 2 > and 3 code paths (I don't see a way to have a single path that works well > under Python 3 while simultaneously supporting 2). I can certainly produce a > patch, but while likely modest, I don't currently have an LO build > environment to verify against Python 2. Is there any chance you might be > able to assist me with a quick sanity check of a patch under Python 2? As "quick" as a LO build is :-)
Ok, proposed patch at https://gerrit.libreoffice.org/6148 I've checked Python 3, and did a crude test against Python 2 by just dumping uno.py into a LO 3.6 installation, and it seems fine If it's possible to test in an actual python-uno build of yours against LO 4.1 that would be great. You can probably cheat as I did and not just temporarily replace the existing uno.py module within the existing installation. For test purposes, an interactive "import uno" followed by any failure in a "from x import y" import form (e.g., a bogus "from x.y import foo" is fine) will trigger the code path.
> You can probably cheat as I did and not just temporarily replace the existing > uno.py module within the existing installation. did so: (sid)root@frodo:/# dpkg -l libreoffice-core python-uno Gewünscht=Unbekannt/Installieren/R=Entfernen/P=Vollständig Löschen/Halten | Status=Nicht/Installiert/Config/U=Entpackt/halb konFiguriert/ Halb installiert/Trigger erWartet/Trigger anhängig |/ Fehler?=(kein)/R=Neuinstallation notwendig (Status, Fehler: GROSS=schlecht) ||/ Name Version Architektur Beschreibung +++-==============-============-============-================================= ii libreoffice-co 1:4.1.2-1 amd64 office productivity suite -- arch ii python-uno 1:4.1.2-1 amd64 Python-UNO bridge (support for ol (sid)root@frodo:/# python Python 2.7.5+ (default, Sep 17 2013, 15:31:50) [GCC 4.8.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import uno >>> from x.y import foo Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib/python2.7/dist-packages/uno.py", line 339, in _uno_import raise uno_import_exc ImportError: No module named x.y (or 'x.y.foo' is unknown) >>>
so looks good
(In reply to comment #6) > so looks good I agree. Stephan, can you assist with having the patch committed? I think it should probably go into 4.1 as well. (The gerrit entry also now includes one tweak to fix a typo in the comments)
David Bolen committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=df1076965f63eedc6cc104c96b993ab598b8b1d4 fdo#70196: Python 2 compatibility for UNO import error handling The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
David Bolen committed a patch related to this issue. It has been pushed to "libreoffice-4-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=2665c114f0adc466efa6ab49cd54d8f633f112fa&h=libreoffice-4-1 fdo#70196: Python 2 compatibility for UNO import error handling It will be available in LibreOffice 4.1.3. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
David Bolen committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=fe4ec778164c8420c187b13c31a44b40622c159a&h=libreoffice-4-0 fdo#70196: Python 2 compatibility for UNO import error handling It will be available in LibreOffice 4.0.7. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 69337 has been marked as a duplicate of this bug. ***