Using pyuno with my existing python installation

问题:

I'm trying to use PyUNO as a method to convert different document formats (doc, wordperfect, html, etc) to PDF from within my Django server. I'm having a heck of a time getting import uno to work. It seems to fail when doing import pyuno, with a message of ImportError: DLL Load Failed: The specified module could not be found.

The only way I can get this to work is to use the Python 2.6 that came with OpenOffice, but I really want to use my other 2.6 installation. The docs for PyUNO are all for Python 2.2, and reputed to be out-of-date.

I'm guessing that some (or all) of the following files need to be copied from the OpenOffice directory to my site-packages directory (or some subdirectory thereof):

pythonloader.py
pythonloader.uno.ull
pythonloader.uno.ini
pythonscript.py
pyuno.pyd

Has anyone had any success getting this to work?

This is on Windows.

回答1:

For simply conversions, you needn't reinvent the wheel. Look at unoconv: http://dag.wieers.com/home-made/unoconv/

'Import uno' will automatically work IF the python interpreter was bundled with OpenOffice, or in some Linux systems where the packagers have done a lot of work for you already.

Alternative 1: For other Python installs on Win32 systems, you need to import three environment variables and add one item to your Pythonpath. The detailed tutorial is at http://user.services.openoffice.org/en/forum/viewtopic.php?f=45&t=36370&p=166783

The three environment variables you must get FROM your OO-installed-Python and add TO your other install of Python are: (Using Python 2.6 and OO 3.1.2)

• os.environ['URE_BOOTSTRAP'] = 'vnd.sun.star.pathname:c:\Program Files\OpenOffice.org 3\program\fundamental.ini'
• os.environ['UNO_PATH'] = 'c:\Program Files\OpenOffice.org 3\program\'
• os.environ['PATH'].append('c:\Program Files\OpenOffice.org 3\URE\bin;c:\Program Files\OpenOffice.org 3\Basis\program;')

The pythonpath item you must add TO your other install of Python is the location of the uno module:

• sys.path.append('C:\Program Files\OpenOffice.org 3\Basis\program')

Now you can simply 'import uno'.

Pyuno is only compatible with a similar version of Python. Since OO 3.1 bundles Python 2.6.1, that pyuno is only compatible with another Python 2.6. Attempting to import uno into a different version of Python will cause a runtime error. But there's a way around that in Alternative 2.

Alternative 2: For other Python installs on WIN32 systems, you can ignore the Python-UNO bridge completely and use the Python-COM bridge instead. You must install one new module, and the API has a few differences, but you can use ANY version of Python, including Python3.

• Install the pywin32module to get COM access: http://sourceforge.net/projects/pywin32/
• Discussion on the API differences: http://user.services.openoffice.org/en/forum/viewtopic.php?f=45&t=36608&p=168179

回答2:

I also need an answer to this. I'm using windows XP and have a system where I extract data from a SQL server DB and insert it into template excel files. I DON'T want to add macro's etc to the OpenOffice. but I want to use the service to produce these files.

However, the only way I seem to be able to import the uno modude is to use the python.exe from the openoffice directory. even then I can't associate this exec with the py files in my system for some reason, thus I have to put in full path names each and every time.

I know that in Linux, the Pyuno module is an addon and can be used in normal python, but in windows this doesn't seem to be the case. I have listed all the relevant path details from the python exec under openoffice and duplicated them in python 2.7, but pyuno still fails with unable to find DDL with no reference to what DDL.

回答3:

I think the answer is "this is not possible." From other reading on the web, it appears that the stdlib used to compile/link the python executable from python.org is different from the stdlib used to compile/link the python.exe distributed with OpenOffice.org. I don't know why, and I'm still confused by the fact that both pythons give me the same startup messages. So I could be completely on the wrong track here.