import of the module doesn't work as expected: $ python >> import pyuno import pyuno Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: No module named pyuno Of course this can be made to work by: PYTHONPATH=/usr/lib/openoffice.org/program/ python Python 2.5.1 (r251:54863, Oct 30 2007, 13:54:11) [GCC 4.1.2 20070925 (Red Hat 4.1.2-33)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import pyuno >>> But this is a suboptimal solution because it causes practical problems with packages that are external to openoffice.org such as bibus. In bug #438527 the noarch package can set the PYTHONPATH to OOo at build-time, but this will fail on x86_64 because it will assume that OOo is located in /usr/lib/ rather than /usr/lib64/. As the bibus maintainer noted on the upstream bug: http://sourceforge.net/tracker/index.php?func=detail&aid=1989580&group_id=110943&atid=657832 "We don't have the problem under debian/ubuntu because we don't have to set the oopath variable because in debian, pyuno is installed as a standard python package. If it is not the case in Fedora, the best would be to ask OOo packagers to do the same than in debian. Just to be clear. On a stock debian: > python >> import uno works without any problem. You don't have to set first: > export LD_LIBRARY_PATH=/usr/lib/openoffice/program > export PYTHONPATH=/usr/lib/openoffice/program " And I agree with him. The Fedora package should emulate the Debian package somehow and be installed in the standard /usr/lib/python2.5/ (or otherwise found without recourse to setting PYTHONPATH). This is will obviate the need for 3rd-party packages such as bibus having to do contortions to simply import pyuno which should be in the default namespace.
debian pulls this off by a rpath to %{_libdir}/openoffice.org/program which our guidelines (http://fedoraproject.org/wiki/Packaging/Guidelines#Beware_of_Rpath) doesn't allow what about... "import uno" rather than directly "import pyuno" which imports pyuno with sufficient magic to make it work
That might be better, but it still means that 3rd-party packages (bibus in this case) will still have special-case for Fedora, since other distros will assume that the module should be able to be imported directly and won't see a need to check for that module name. Which brings us back to the original problem. Is there any reason why OOo can't install it in the usual place and look for it there? I know it's very tied to OOo, but it is a Python module, after all.
I suspect that "import uno" will also works on debian et. al. If it did, that'd be ideal. pyuno.so does a dlopen(libpyuno.so). So if pyuno.so is moved into the python lib dir then libpyuno.so must either be moved in there as well, and if that's moved in there then the global linker or python path has to extended to /usr/lib/openoffice.org because libpyuno.so links against a stack of stuff in that dir, both options are sort of horrific. Like I said, the debian workaround is probably the patch I see in ooo-build of... + @echo $(LINK) -Wl,-z,combreloc $(LINKFLAGS) $(LINKFLAGSRUNPATH_OOO) -Wl,-rpath,/usr/lib/openoffice/program $(LINKFLAGSSHLCUI) -ldl -o $@ $(SLO)$/pyuno_dlopenwrapper.o > $(MISC)$/$(@:b).cmd which isn't acceptable by http://fedoraproject.org/wiki/Packaging/Guidelines#Beware_of_Rpath
well "import uno" will work, and I think will work on all systems, and bring in pyuno so that might be a suitable global upstream solution. If someone can figure out a way to place pyuno in the right place to allow "import pyuno" to work without violating the rpath guidelines then I'm all for it. Maybe when the dust has settled on the 3 layer OOo it might be possible to see a route towards placing the ure libs in standard /usr/lib path, and that might work. But I'm not sure that it would be sufficient
If "import uno" works at the moment in actual release, then this should be closed. But if it doesn't yet work, then it should be kept open. I'm not sure why it should be closed CANTFIX, at the least, it could be closed as UPSTREAM, since it might be fixed there.
This definitely doesn't work on F-8: $ python Python 2.5.1 (r251:54863, Oct 30 2007, 13:54:11) [GCC 4.1.2 20070925 (Red Hat 4.1.2-33)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import uno Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: No module named uno but it does on F-9: $ python Python 2.5.1 (r251:54863, Apr 8 2008, 01:19:33) [GCC 4.3.0 20080404 (Red Hat 4.3.0-6)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import uno >>> uno (all with most recent updates)