Bug 450692 - [pyuno] pyuno should be in default PYTHONPATH
Summary: [pyuno] pyuno should be in default PYTHONPATH
Alias: None
Product: Fedora
Classification: Fedora
Component: openoffice.org
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Caolan McNamara
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: 438527
TreeView+ depends on / blocked
Reported: 2008-06-10 13:49 UTC by Alex Lancaster
Modified: 2008-06-13 12:36 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-06-13 12:17:19 UTC
Type: ---

Attachments (Terms of Use)

Description Alex Lancaster 2008-06-10 13:49:37 UTC
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

As the bibus maintainer noted on the upstream bug:


"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.

Comment 1 Caolan McNamara 2008-06-10 14:08:03 UTC
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

Comment 2 Alex Lancaster 2008-06-10 14:19:14 UTC
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.

Comment 3 Caolan McNamara 2008-06-10 14:33:02 UTC
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

Comment 4 Caolan McNamara 2008-06-13 12:17:19 UTC
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

Comment 5 Alex Lancaster 2008-06-13 12:34:50 UTC
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.

Comment 6 Alex Lancaster 2008-06-13 12:36:48 UTC
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)

Note You need to log in before you can comment on or make changes to this bug.