Monday 21 July 2008

Scripting OpenOffice.org from Python - too hard

How hard should it be? I wanted to drive the OpenOffice.org Calc app from an external copy of Python under windows, and I've given up trying.

I can do it very easily in Excel, using the COM interface, but OOo has me beaten.

I've got a Python script that I use in a test environment, to put the results directly into a spreadsheet report. I'm running Python 2.5.2 and OOo 2.4.

I start to read the documentation, and it says there's a Python module I can use (uno) - great, says I - where do I get it from? It seems that its included with the OOo installation, in the 'program' directory - excellent! So I add the program directory to my Python path:

import sys
sys.path.append(r"C:\Program Files\OpenOffice.org 2.4\program")

and import it,

import uno

and I immediately get the following excepion: 'ImportError: No module named pyuno'. It seems that pyuno is a DLL library that uno needs.

Where do I go from there? I get a vague hint from the documentation that I may need to re-build the DLL for my version of Python. Ouch! It shouldn't be this hard. I haven't got time to get the the bottom of this. Why is this a DLL? What's wrong with a good old .py file. Its not like there's some proprietary technology that needs to be protected within the DLL.

At this point, I've given up on OOo, for this project at least, and I'll be going back to Excel, with its good old COM interface. I'd rather be using Open-Source software, but on this occasion, its too difficult. A pity.

3 comments:

Michael Foord said...

The dll probably wraps the OOo C API - which is why it will be written in C.

cowmix said...

Is there a specific reason you have to use Python 2.5.? For most of my OOo scripting purposes the 2.3.5 version that ships with OOo (for Windows) seems to work just fine.

Also, if you NEED 2.5.X, OOo under Ubuntu will work.

Jon said...

Thanks for the replies.

I think my frustration was really about the lack of a more portable/standard external API for OOo. Something like SOAP or XML-RPC would be nice - although I appreciate that adding an HTTP/XML server adds a whole other layer of complexity.

In this case, I also needed to interface with a SQLite DB file - hence the reason for using 2.5.x, rather than 2.3 (batteries included etc.).

Also, running on Ubuntu was not an option - because I was installing the stuff on a customer's machine.

I don't especially like the Excel COM interface, but at least it works out of the box, and works on different versions.

Given the limited time I had available to get this stuff working, the barrier for entry with OOo was too high for me. Given a bit more time I might have been able to get in running with OOo (after rebuilding the DLL), but in the end, it was easier (but more costly to my customer) just to install Excel.

I'd much rather be using OOo under these circumstances.