Python-Uno Brücke

Probleme bei der Installation?
Antworten
Sec
User
Beiträge: 16
Registriert: Montag 24. März 2014, 22:53

Gerne möchte LibreOffice "headless" auf einen Web-Server nutzen, um damit zum Beispiel aus .ott-Vorlagen .pdf-Dateien für den Download zu generieren. LibreOffice soll von einen CGI in Python3 aus aufgerufen werden und weil der Server unter Ubuntu 12.4 läuft konnte ich Python2.7 nicht überschreiben sondern habe Python3.4 nach der empfohlenen Methode (./configure, make, make test, make altinstall) parallel aus den Sourcen installiert. Dann war LibreOffice dran und aptitude install libreoffice machte seinen Job bis auf eine kleine Ausnahme gut. Die Python-Uno-Brücke landete nur in Python2.7 nicht aber in Python3.4. Also ist in Python3.4 Essig mit import uno.
Ansich ist das Paket python-uno ja auf meinem Server. Wenn ich aber aptitude install python-uno aufrufe, meint aptitude, dass nichts mehr zu tun ist, weil das Paket ja schon in Python2.7 installiert ist. Ein getrennt herunter ladbares setup.py für python-uno, das ich in python3.4 starten könnte hab ich trotz intensiven googlens nicht gefunden.
Weiß jemand wie ich aus dieser Sackgasse wieder raus kommen kann?
BlackJack

@Sec: Ich würde sagen da kannst Du nicht viel machen wenn es die UNO-Bridge für Python nicht separat gibt. Selbst wenn, wäre die nächste Frage ob es die auch für Python 3.x gibt.

Brauchst Du denn überhaupt UNO? Das ist keine schöne API. Man kann Dateien auch über einen Aufruf auf der Kommandozeile drucken, also von Python aus auch über das `subprocess`-Modul. So etwas wie ``libreoffice --headless --convert-to pdf something.ott`` sollte zu einer ``something.pdf`` führen.
Sec
User
Beiträge: 16
Registriert: Montag 24. März 2014, 22:53

In der Vorlage sind natürlich ein paar Platzhalter. Auch wenn ich deren Substitution über LibreOffice Basic Makros realisere brauch ich nach meinem bisherigen Kenntnisstand uno, um eine funktionierende Parameterübergabe hin zu bekommen.
Auch, wenn sich Dein Beitrag eher wie ein schlechte Nachricht liest: Danke BlackJack!
Sec
User
Beiträge: 16
Registriert: Montag 24. März 2014, 22:53

Noch eins: Wie soll denn bitte Apache die python-uno bridge in 2.7 rein drücken, wenn Apache kein setup.py hat? Also irgendwie muss sich das tricksen lassen.
Sec
User
Beiträge: 16
Registriert: Montag 24. März 2014, 22:53

Außerdem: Hier in meiner "privaten" Entwicklungsumgebung mit einem Apache2 auf Ubuntu 13.10 läuft das Ganze einwandfrei. Nur auf dem vServer von einem anerkannt guten Provider hab ich dieses Problem. Also an Python3.x kann's nicht liegen.
BlackJack

@Sec: Mit dem vorletzten Beitrag von Dir kann ich nichts anfangen. Was willst Du damit sagen?

Also die UNO-Brücke gibt es offensichtlich auch für Python 3, da bleibt allerdings immer noch das Problem dass Du die irgendwie für Dein selbst kompiliertes Python 3.4 installieren musst. Sofern das überhaupt vernünftig machbar ist, ohne dass man LibreOffice selber übersetzt.

Ich habe ein ähnliches Problem gelöst in dem ich ein Tabellendokument einfach direkt bearbeite, also die `content.xml` in dem Archiv. Kommt halt drauf an wie aufwändig das in Deinem Fall wäre.
Sec
User
Beiträge: 16
Registriert: Montag 24. März 2014, 22:53

Präzisiere: Ubuntu 13.10 Standardinstallation, also mit 2.7 und 3.3.2+. Natürlich war direkt nach der Neuinstallation von Ubuntu 13.10 kein Python3 drauf, aber LibreOffice. Dann Python3 über die Wundertüte (Ubuntu Software Center) mit dem Ergebnis 3.3.2+ nachinstalliert. Und dann die IDLE ausgerufen: import uno - bingo! Hat sofort gefunkt. Vielleicht liegt es daran, dass ich auf dem vServer "make altinstall" anstatt "make install" aufgerufen habe. Um "make install" aufzurufen, fehlte mir auf Ubuntu 12.4 einfach der Mut. Zum Schluss hätte mir der vServer die 2.7 Installation so wie bei x Ubuntu-Versionen vorher einfach überschrieben und dann geht ohne Neuinstallation des OS bekanntlich nix mehr. Irgendwie hängen alle Linux-Distributionen noch am Tropf von Python2.x.
BlackJack

@Sec: Wenn mit dem Python 3 aus der Paketverwaltung ein ``import uno`` funktioniert, dann hast Du auch das Paket `python3-uno` installiert, entweder explizit oder über ein Metapaket als Abhängigkeit.

Ob dieses Paket aus der Paketverwaltung auch mit einer selbst kompilierten anderen Python-Version, also zum Beispiel 3.4 funtkioniert, ist nicht sicher, denn weder bei Bytecode-Dateien noch bei der C-API ist garantiert, dass beim Wechsel der Minor-Version, also der Zahl nach dem ersten Punkt, kompatibel sind/bleiben. Selbst wenn es sich importieren lässt muss nicht alles funktionieren.

Man braucht also eine `pyuno`-Bibliothek, die zu dem selbst installierten Python passt. Wenn man zu dem Thema im Netz sucht, findet man keinen Weg beschrieben wie man sich den `pyuno`-Teil für das selbst installierte Python übersetzen kann, also würde das wohl letztendlich auf ein selbst kompilieren von LibreOffice hinaus laufen. Was ich mal als nicht praktikabel einstufen würde, wenn man nicht gerade masochistisch veranlagt ist; und zu viel Zeit, Speicher, und Rechenleistung übrig hat. :-)

Ich würde sagen man nimmt entweder eine der Python-Versionen die von der Distribution für die Zusammenarbeit mit LibreOffice angeboten werden, oder man sucht nach einem anderen Weg.
Sec
User
Beiträge: 16
Registriert: Montag 24. März 2014, 22:53

Das Dist-Package enthält auf meiner Ubuntu13.4 installation enthält neben den Python-Sourcen leider pyuno.so. Also brauch ich wahrscheinlich ne Source. Die habe ich jetzt auch bei Debian gesucht, aber immer noch nicht gefunden.

In uno.py aus dem dist-package steht direkt nach dem einleitenden Kommentar und den Importen folgender Code:

Code: Alles auswählen

try:
    unicode
except NameError:
    # Python 3 compatibility
    unicode = str
Jetzt mal ganz pervers: Ich kopiere pyuno.so auf dem vServer aus der Python2.7-Installation in die Python3.4-Installation. Dann lade die Python3.3-Bibliotheken aus meiner Ubutntu13.4-Installation hoch und kopiere diese ebenfalls in die Python3.4-Installation. Meinst Du, dass das klappen könnte?
BlackJack

@Sec: Nein das dürfte nicht klappen. Versuchen kannst Du es natürlich. Aber von 2.x auf 3.x hat sich die C-API sehr wahrscheinlich stark genug geändert, dass das nicht einfach so gehen wird. Zumal die `pyuno.so` ziemlich sicher gegen die `libpython2...` auf dem System gelinkt sein wird.

Den Quelltext findest Du nicht separat weil `pyuno` Bestandteil von LibreOffice ist, also kompiliert wird, wenn man LibreOffice kompiliert. Deswegen ja auch meine Befürchtung dass man genau das machen muss wenn man eine Python-Version verwenden möchte, für die es kein Paket von `pyuno` in der Linux-Distribution gibt. Und bevor man das angeht, würde ich eher nach Alternativen suchen. Also zum Beispiel die Platzhalter ohne Hilfe von LibreOffice füllen, oder vielleicht einen kleinen Server schreiben der mit einer Python-Version läuft die als Paket von der Distribution angeboten wird, und der beispielsweise eine JSON-RPC-API bietet um das zu machen was Du vorhast.
Sec
User
Beiträge: 16
Registriert: Montag 24. März 2014, 22:53

@BlackJack: Von Deinen Vorschlägen gefiel mir zum Schluss die Lösung mit dem kleinen Demon in Python2.7 am besten. Und wie das Leben so spielt, war ich dann doch mal auf der Debian-Site und wurde fündig: Auf "http://www.debian.org/distrib/packages" kann man nach Paketen suchen: Ganz weit runter scrollen, bis die Suchmaske erscheint; python3-uno eingeben; im Suchergebnis wieder tüchtig runter scrollen und gibt's für alle möglichen Architekturen Pakete.

Vielen Dank BlackJack, dass Du mich so treu begleitet hast. War echt Klasse.
Den Knopf um die Aufgabe als (mehrfach) gelöst zu markieren, finde ich nicht. Macht's Du das in diesem Forum?

Zum Abschluss noch eine Gewissensfrage: OS = Ubuntu12.04, Python2.7 war vorinstalliert, Python3.2 hab ich mit aptitude nachgeschoben und Python3.4 hatte ich aus den Source mit "make altinstall" installiert. Wenn ich nun statt dessen "make install" aufrufe, ersetzt make dann wie von mir intendiert 3.2 durch 3.4 oder macht es alles kaputt?
Zuletzt geändert von Sec am Dienstag 25. März 2014, 14:55, insgesamt 1-mal geändert.
BlackJack

@Sec: Ich vermute es macht ”alles kaputt”. Zumindest wenn es noch das gleiche wie bei Python 2 macht, wird `python` zum Synonym für `python3.4` und wenn das System bei `python` ein Python 2.x erwartet, werden Programme und Systemskripte die sich darauf verlassen, nicht mehr funktionieren.

Das ”alles kaputt” ist in Anführungszeichen weil `python` in der Regel nur ein symbolischer Link auf das Standardpython ist und die tatsächlichen Binärprogramme die Versionsnummer im Namen haben. Wenn so ein ``make install`` also aus versehen passiert, kann man danach einfach den Link wieder auf den ja immer noch installierten Standardinterpreter setzen. Mal ein paar Beispiele von einem Rechner an dem ich gerade angemeldet bin:

Code: Alles auswählen

$ ls -l $(which python)
lrwxrwxrwx 1 root root 9 2012-02-21 12:10 /usr/bin/python -> python2.7
$ ls -l $(which python3)
lrwxrwxrwx 1 root root 9 2013-02-12 14:54 /usr/bin/python3 -> python3.2
$ ls -l $(which python3.1)
-rwxr-xr-x 1 root root 2612892 2012-10-23 23:04 /usr/bin/python3.1
Das 3.2 ist selbst übersetzt. (Ja das System könnte mal eine Aktualisierung vertragen.)
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

BlackJack hat geschrieben:@Sec: Ich vermute es macht ”alles kaputt”. Zumindest wenn es noch das gleiche wie bei Python 2 macht, wird `python` zum Synonym für `python3.4` und wenn das System bei `python` ein Python 2.x erwartet, werden Programme und Systemskripte die sich darauf verlassen, nicht mehr funktionieren.
Hatte es gestern erst mit Python 3.4.0 versucht und da wird Python als ``python3`` und ``python3.4`` installiert (und ``python3.4m``).
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Antworten