Apache OpenOffice (AOO) Bugzilla – Issue 97629
Do not start OOo from PyUno
Last modified: 2009-04-01 09:08:23 UTC
Steps: 1. Save as file errUno.txt simple script: [code] from officehelper import bootstrap xContext = bootstrap() [/code] 2. Open cmd 3. Change current directory to directory contains errUno.txt (cd ...) 4. Run script: $(OOOInstallDir)\program\python.exe" errUno.txt 5. See error log in console output. My error output: [code] C:\Lang\test\python>"C:\Program Files\OpenOffice.org\OpenOffice.org 3\program\python.exe" text.py C:\Lang\test\python>Traceback (most recent call last): File "text.py", line 5, in ? xContext = bootstrap() File "C:\Program Files\OpenOffice.org\OpenOffice.org 3\Basis\program\officehelper.py", line 91, in bootstrap raise BootstrapException("Caught exception " + str(e), None) officehelper.BootstrapException: Caught exception [Errno 2] No such file or directory [/code]
Created attachment 59052 [details] Test script
This seems to be related to having the brand factored out (three layer office), going to discuss this tomorrow with Stephan B.
Stephan, please have a look ...
@jbu: officehelper.py (per default left in the basis layer program directory after the three layer split) expectes to find the soffice executable next to itself (which no longer works, as the soffice executable moved to the brand layer). When the OOo-specific python executable (from the brand layer program directory) is used, it already modifies PYTHONPATH so that files like officehelper.py are found in the first place (and code like "from officehelper import bootstrap" works at all). Something similar could be used to communicate from the OOo-specific python executable (which can know where soffice is located) to officehelper.py (which cannot know by itself, if it remains in the basis layer) where soffice is located. (For example, using the UNO_PATH environment variable that is already used, somewhat related, in cppuhelper_detail_findSofficePath.) However, when a system-provided python executable is used instead (i.e., OOo is configured to not provide an own python executable), I am unsure how such a mechanism could work, but I am also unsure whether code like "from officehelper import bootstrap" would work there in the first place, as PYTHONPATH would probably not be set accordingly (we already discussed that before, but I cannot remember that this general problem was solved).
fixed as cws/sb103/pyuno/zipcore/python.cxx@266375 cws/sb103/pyuno/zipcore/python.sh@266375 cws/sb103/scripting/source/pyprov/officehelper.py@266375 cws/sb103/tools/source/misc/extendapplicationenvironment.cxx@266375 This of course only fixes the problem when the OOo-specific python executable (from the brand layer program directory) is used, not when a system-provided python executable is used instead (i.e., OOo is configured to not provide an own python executable). Executing the attached errUno.txt with the OOo-specific python executable (from the brand layer program directory) now no longer gives error messages (doing so leaves a running soffice executable showing no windows behind; that is expected and is due to what errUno.txt does). On Windows, the started soffice executable shows a message box that "C:\3\program\soffice.exe does not exist." This is apparently due to a space in the path to the soffice executable (C:\OpenOffice.org 3\program\soffice.exe); probably the os.spawnv in officehelper.py causes soffice.exe to see the second part of the program path ("3\program\soffice.exe") as an additional command line argument that soffice.exe makes absolute and interprets as a document to open. Older OOo 2.x versions on Windows exhibit similar behavior (and the problem disappears when OOo is installed in a path without spaces).
@jsk: please verify
I can confirm that there are now two messageboxes complaining about the missing file (as noted by SB above). However, i when using an installation path without spaces the office does not start. Is this intended? According to the statement above i should expect the office to open in backing mode. @SB: Please clarify
@jsk "the office does not start": The office should start (and continue running afterwards), but not display any windows (not even the start center).
Verified.
Closing, all good on MWS ooo310m6
> This of course only fixes the problem when the OOo-specific python executable > (from the brand layer program directory) is used, not when a system-provided > python executable is used instead (i.e., OOo is configured to not provide an own > python executable). Bad. Will this one day also be fixed for system-python builds? (It makes no sense for distros to ship an ancient, security buggy python internally which disallows even the usage of "standard" external modules instead of just using the python it has already - and all the modules with it..)
@rene: See <#desc5> for my doubts that using officehelper.py together with a system python executable ever worked at all. Certain environment variables need to be set/extended for that to work: PYTHONPATH always needed to be extended so that officehelper.py is found, now UNO_PATH additionally needs to be set so that officehelper.py finds the soffice executable. I would suggest you file a fresh issue to clarify how officehelper.py together with a system python executable is supposed to work. If we know what needs to be done to address the PYTHONPATH problem (which existed before the UNO_PATH problem), I am sure it is easy to extend that to also address the UNO_PATH problem.
> @rene: See <#desc5> for my doubts that using officehelper.py together with a > system python executable ever worked at all. Certain environment variables need That can be. Surely I didn't have soffice in /usr/lib/python2.5/site-packages :) > to be set/extended for that to work: PYTHONPATH always needed to be extended so so far I have it directly in site-packages. Though that probably breaks now in 3.1, too whereas it worked in 3.0.1 :( > that officehelper.py is found, now UNO_PATH additionally needs to be set so that > officehelper.py finds the soffice executable. I would suggest you file a fresh > issue to clarify how officehelper.py together with a system python executable is > supposed to work. If we know what needs to be done to address the PYTHONPATH Why me? I didn't break this and system-python is there since a long time... Besides that, you are the expert on UNO and what is allowed in the three-layer OOo and what not...
But I think I'll just do that for now: --- scripting/source/pyprov/officehelper.py-old 2009-03-31 00:08:59.000000000 +0200 +++ scripting/source/pyprov/officehelper.py 2009-03-31 00:10:08.000000000 +0200 @@ -57,7 +57,7 @@ if "UNO_PATH" in os.environ: sOffice = os.environ["UNO_PATH"] else: - sOffice = "" # lets hope for the best + sOffice = "/usr/lib/openoffice/program" sOffice = os.path.join(sOffice, "soffice") if platform.startswith("win"): sOffice += ".exe" since we know in our packages where OOo is.
In Windows this patch incorrect. Default path for soffice is "C:\Program Files\OpenOffice.org 3\program\". For officehelper.py is "C:\Program Files\OpenOffice.org 3\Basis\program" Relative from officehelper.py is [code] import os, os.path as osp dn = osp.dirname print osp.join(dn(dn(dn(__file__))), 'program') [/code]
if you mean my patch, of course it's not. It's only suitable for Linux distro packages who install their stuff in /usr/lib/openoffice. No one claimed it was a correct patch for Windows nor in all other cases. It was just for reference :)
I added UNO_PATH to the list of things in issue 90701 that need to be addressed to make system Python work.