Bug 116156 - Python // officehelper.py misbehaves since 5.3.7
Summary: Python // officehelper.py misbehaves since 5.3.7
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
5.3.7.2 release
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Not Assigned
URL: https://wiki.documentfoundation.org/M...
Whiteboard:
Keywords:
Depends on:
Blocks: Macro-Python
  Show dependency treegraph
 
Reported: 2018-03-03 10:53 UTC by LibreOfficiant
Modified: 2020-11-06 10:19 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description LibreOfficiant 2018-03-03 10:53:23 UTC
Description:
officehelper.py module bootstrap() function does not connect or connects with annoying msgbox(es) that state that LibreOffice/soffice can't be found.

Works fine with 5.2.3

Steps to Reproduce:
1. Open LibreOffice Python interpreter
2. type " import officehelper as oh "
3. type " oh.bootstrap() "

Actual Results:  
Python 3.5.4 (default, Jan 30 2018, 19:34:57) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import officehelper as oh
>>> oh.bootstrap()
Traceback (most recent call last):
  File "C:\Program Files\LibreOffice 5\program\officehelper.py", line 72, in bootstrap
    xContext = resolver.resolve(sConnect)
uno.NoConnectException: Connector : couldn't connect to pipe uno5434955891389311(1)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Program Files\LibreOffice 5\program\officehelper.py", line 77, in bootstrap
    raise BootstrapException("Cannot connect to soffice server.", None)
officehelper.BootstrapException: Cannot connect to soffice server.

Expected Results:
Python 3.5.4 (default, Feb  8 2018, 19:35:03) [MSC v.1900 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.>>> import officehelper as oh
>>> oh.bootstrap()
pyuno object (com.sun.star.uno.XInterface)0x47c0dac{, supportedInterfaces={com.sun.star.uno.XComponentContext,com.sun.star.container.XNameContainer,com.sun.star.lang.XTypeProvider,com.sun.star.uno.XWeak,com.sun.star.lang.XComponent}}
>>>


Reproducible: Always


User Profile Reset: No



Additional Info:
Versions 5.4 & 6.x typically display msgbox(es)


User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0
Comment 1 Buovjaga 2018-03-10 14:49:07 UTC
I tried running the LibO Python on Win, but it complained about a missing python35.dll.
I don't know how to import the officehelper using system Python. I tried on Linux.

Adding Xisco as he is Mr Python.
Comment 2 mini-matze 2018-06-14 09:57:34 UTC
I could confirm the bug. I don't know how it could work before, but the bug is the first given parameter to spawnv which is not quoted (and the path has spaces in windows).

If you change the line

cmdArray = (sOffice, "--nologo", "--nodefault", "".join(["--accept=pipe,name=", sPipeName, ";urp;"]))

to

cmdArray = ('"{}"'.format(sOffice), "--nologo", "--nodefault", "".join(["--accept=pipe,name=", sPipeName, ";urp;"]))

it works fine. I don't know how its with linux. When it's there a problem, you could add a sOfficeQuoted variabel and decide in the "if" above (for the extension) to quote or not the "sOffice" variable!

@Buovjaga
You should use the python.exe in the folder "C:\Program Files (x86)\LibreOffice 5\program"! Not the one in the subfolder bin (this is called by the oher python.exe with needed environment variables)
Comment 3 Buovjaga 2018-06-14 10:00:05 UTC
(In reply to mini-matze from comment #2)
> @Buovjaga
> You should use the python.exe in the folder "C:\Program Files
> (x86)\LibreOffice 5\program"! Not the one in the subfolder bin (this is
> called by the oher python.exe with needed environment variables)

Yes, it seems this is my Achilles' heel - recently I asked about it on IRC and was told to use the python.exe wrapper.
Comment 4 mini-matze 2018-06-14 10:55:20 UTC
I think a more better solution were to use subprocess instead of the "old" os.spawn. So we need not care about quoting (and to set it as first arg, too).

add to imports:
from subprocess import Popen

Then we need to replace the process creation:
replace:
    os.spawnv(os.P_NOWAIT, sOffice, cmdArray)
with:
    Popen( cmdArray )


Or alternativ (because the first arg is the path to use - it's cleaner):
replace:
    cmdArray = (sOffice, "--nologo", "--nodefault", "".join(["--accept=pipe,name=", sPipeName, ";urp;"]))
    os.spawnv(os.P_NOWAIT, sOffice, cmdArray)
with:
    cmdArray = ("--nologo", "--nodefault", "".join(["--accept=pipe,name=", sPipeName, ";urp;"]))
    Popen( (sOffice,) + cmdArray )


Hope this helps...
Comment 5 LibreOfficiant 2018-06-14 12:08:21 UTC
If I'm not wrong, subprocess.Popen objects are designed as context managers that handle resource allocation and releasing, which os.spawn may miss.

Can I invite you to check for https://gitlab.com/LibreOfficiant/ide_utils project? 

It's been built on top of officehelper in order to ease Python macros development for LibreOffice and OpenOffice within IDE's such as Geany and PyCharm.

It may extend officehelper features and promote Python macros development within LibreOffice.

Notice its @retry decorator that leverages connection attempts.
Comment 6 LibreOfficiant 2018-06-16 10:38:31 UTC Comment hidden (obsolete)
Comment 7 LibreOfficiant 2018-06-16 10:41:52 UTC
(In reply to Alain H Romedenne from comment #6)
> First of all let me say you're free to modify officehelper.py any time you
> want.
> 
> However let me point out that "that very same code" is functioning fine in:
> o  OpenOffice
> o  LibreOffice 64 bits up to version 5.3.7 excluded
> o  LibreOffice 32 bits all PortableApps versions
> At first sight, something has been modified in LibreOffice itself or within   
> Python 3 itself from release 5.3.7.
> 
> I tend to think that solely modifying officehelper.py code, for good, may
> leave the root cause of the module's misbehaviour unidentified.
> 
> Cordially
Comment 8 QA Administrators 2019-06-17 02:47:23 UTC Comment hidden (obsolete)
Comment 9 LibreOfficiant 2019-06-19 13:46:37 UTC
retested successfully under Windows

Version: 6.2.4.2 (x64)
Build ID: 2412653d852ce75f65fbfa83fb7e7b669a126d64
CPU threads: 12; OS: Windows 10.0; UI render: GL; VCL: win; 
Locale: en-IE (en_IE); UI-Language: en-GB
Calc: threaded
Comment 10 LibreOfficiant 2019-06-24 12:59:06 UTC
retested unsuccessfully under Linux

Version: 6.2.4.2
Build ID: 1:6.2.4-0ubuntu0.19.04.1
Threads CPU: 1; Os : Linux 5.0; UI Render : par défaut; VLC: gtk3;
Locale : fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR
Calc: threaded
Comment 11 Buovjaga 2019-06-24 13:48:02 UTC
(In reply to LibreOfficiant from comment #10)
> retested unsuccessfully under Linux
> 
> Version: 6.2.4.2
> Build ID: 1:6.2.4-0ubuntu0.19.04.1
> Threads CPU: 1; Os : Linux 5.0; UI Render : par défaut; VLC: gtk3;
> Locale : fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR
> Calc: threaded

Then we should put back to NEW.
Comment 12 LibreOfficiant 2019-06-24 14:03:59 UTC
retested unsuccessfully under Linux with APPIMage file 

Version: 6.2.4.2
Build ID: 241265....126d64
Threads CPU: 1; OS : Linux 5.0; UI Render : par défaut; VLC: gtk3;
Locale : fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR
Calc: threaded