On 2010-03-01 7:23 PM, Rene Engelhard wrote:
>
> Besides the factthat basing a important project on *unstable* is questionable
> anyway, I'd very much buiild against 2.6, too - if it was default python.
> Ask the python guys why this isn't yet and when it will be. Not me.
The project spans at least 3 platforms. Testing/QA servers are my
responsibility and run debian unstable, because it has almost everything
I need and I don't want to repeat the horror of SLES 10 production
servers there :(
>>> I build only for the default python and this is not going to change.
>>> Especially it will get interesting because pyuno is not a pure python#
>>> module but has also a OOo part (which is linked against libpython).
>>>
>>> Which one of both will you take? Both will conflict anyway due to
>>> the pythonloader. And the build will also get hackish. ("Normal" build
>>> of OOo and then pyuno again for 2.6).
>>>
>>> René
>>
>> Obviously I wanted files for both versions, including OOo parts, maybe
>> installed to python2.6 lib dirs directly. I agree this is not easy and
>
> No way. pythonloader.uno.so has to be in OOos dirs. Really.
> So, yes, you would not be able to co-install them.
>
>
>> instead, but after looking at debian/rules again I doubt anyone else
>> wants to understand and reproduce even parts of it.
>
> They won't do anything there either, this is simply not only a pure
> python module, but also python integration *inside* OOo. For macros,
> etc. It embeds the python interpreter via libpython.
Ok here we are at the root of the problem. I do *not* want another
python interpreter inside OOo. I fully understand there's only one, and
that's the debian default version.
I want the necessary UNO libs to access the UNO bridge from the outside,
from a different python interpreter than running inside OOo, even from a
different version. After all it should be possible from java or any
other language too, even networked from other hosts.
In short I wanted the following to work with python2.6:
~/% python
Python 2.5.5 (r255:77872, Feb 1 2010, 19:53:42)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import uno
>>> uno.getComponentContext()
pyuno object (com.sun.star.uno.XComponentContext)0x96e9d88{,
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}}
If this is not possible I feel UNO fails miserably at its design goal.
What good is a bridge if I can't access it without linking against the
exact same software running on the other side?
Maybe you could split the package providing the python loader for inside
OOo and the UNO bindings for system python. Maybe the python guys should
provide the bindings and a separate UNO client lib for each python version.
For my project, we'll do without UNO for now.
regards,
Jürgen
Attachment:
signature.asc
Description: OpenPGP digital signature