Python statisch binden

jhamel · Samstag 12. Mai 2012, 11:36

Hallo,
Durch die Situation mit verschiedenen python-Versionen ( Hauptsächlich 2 und 3, unterschiedliche Modul Namen in verschiedenen Linux-Distros, unterschiedliche, inkompatible Modulversionen, etc. ) habe ich immer mehr Probleme mit meinen Programm(CUON) Der Zeitaufwand für die installation beim Benutzer ist enerom angewachsen. Jetzt bin ich auf die Idee gekommen, das ganze statisch zu binden, das heißt eine komplette python Installation mit allen Modulen, die mein Programm benötigt, in dem Programmverzeichnis zu hinterlegen. Die Struktur im Homeverzeichnis des Benutzer sieht so aus:
/home/user/cuon

Dazu habe ich mehrere Fragen:
Muß ich für jedes Linux und Windows eine eigene Struktur angeben? Also so:
/home/user/cuon /linux_i686
/linux_x86_64
/windows_xp32
/windows_7_32
/windows_7_64

reicht das, oder muß ich für verschiedene linux-Distros die Pfade ebenfalls einfügen ?
Mein Programm umfaßt ca. 350 Python Dateien, muß ich in jeder einen codeblock mit den Python Path anfügen ? Oder kann man das global machen, in der main Datei ?
Kann ich von verschiedenen Systemen die Python Installation einfach kopieren oder muß ich jeweils eine neuinstallation in ein bestimmtes Verzeichnis, z.B. $HOME/cuon/linux_i686 machen ?

Danke schon mal für eure Hilfe.

Tschüss
Jürgen

Hyperion · Samstag 12. Mai 2012, 12:36

Ich muss gestehen, mir sind einige Argumente (Probleme) Deinerseits unklar. Wenn ich das richtig verstehe, willst Du eine bestimmte Anzahl an "Bundles" für die gängigen OS erstellen, damit der Installationsaufwand sich verringert.

Aber dann musst Du doch diese Bundles pflegen!? Ist das nicht vom Aufwand identisch?

Für die Installation solltest Du doch mittels `distribute` ein Paket zusammenstellen können, welches alle Abhängigkeiten (und da die kompatiblen Versionen) berücksichtigt. Wenn Du das dann Client seitig in einer `virtualenv`-Umgebung installierst, sehe ich da ehrlich gesagt nicht die von Dir ausgemalten Schwierigkeiten...

Das "schwierige" wäre dann nur noch, `virtualenv` und `pip` auf der Zielplattform zu installieren

lunar · Samstag 12. Mai 2012, 13:20

@jhamel: Versehe Dein Programm mit einer distutils/setuptools-Installationsroutine, wie in der Python-Dokumentation und auf http://packages.python.org/distribute/ beschrieben. Dann lässt sich Dein Programm per "python setup.py install" oder mit "pip" installieren, und Dir stehen diverse weitere Tools zur Verteilung zur Verfügung.

Linux-Nutzern kannst Du dann ein per "python setup.py sdist" erzeugtes Archiv geben, und ihnen die Installation per "python setup.py install --user" zu erklären. Ferner kannst Du Dein Programm im Paketindex hochladen, so dass Nutzer das Programm direkt mit "pip install --user DeinProgramm" installieren können, ohne es vorher herunterladen zu müssen. Falls Du Zeit und Lust hast, kannst Du sogar Pakete für verschiedene Distributionen im Suse Open Build Service bauen. Sofern Dein Paket eine oben beschriebene Standard-Installationsroutine hat, ist es nicht sonderlich schwierig, daraus Paketbeschreibungen für verschiedene Distributionen zu erzeugen. Das Bauen übernimmt dann der Build-Service, Du brauchst dann lediglich auf die Build-Service-Download-Seite Deines Programms zu verlinken.

Für Windows kannst Du ausgehend von Deiner "setup.py" mit "py2exe" oder "pyinstaller" eigenständige Python-Pakete für Dein Programm schnüren, und Dein Programm so als unabhängige EXE-Datei weitergeben.

Das alles setzt natürlich voraus, dass Du Dein Programm mit einer solchen Installationsroutine versiehst. Wenn Dein Programm diese noch nicht hat, dann rate ich Dir nachdrücklich dazu, es damit zu versehen. Was Du da jetzt nämlich vorhast, ist nicht nur enorm aufwendig für Dich selbst, sondern wird Dir auch von jedem halbwegs erfahrenen Linux-Nutzer und -Admin um die Ohren gehauen.

jhamel · Samstag 12. Mai 2012, 13:31

Hyperion hat geschrieben:Ich muss gestehen, mir sind einige Argumente (Probleme) Deinerseits unklar. Wenn ich das richtig verstehe, willst Du eine bestimmte Anzahl an "Bundles" für die gängigen OS erstellen, damit der Installationsaufwand sich verringert.

Ja, das ist richtig. Dies wäre eine Lösung für mich, wenn es OS-Basiert geht, also Distributionsunabhängig ist. Die Probleme sind ziemlich simple, ich muß zur Zeit z.B. für verschiedenste Distris immer wieder die Python Paketnamen raussuchen, und immer wieder meine imports anpassen, z.B. so:

Code: Alles auswählen

try:
    import Image
except:
    print "no package Image found, try PIL"
    try:
        from PIL import Image
    except:
         print "last Try: no package Image found"

oder so:

Code: Alles auswählen

GtkSV = True 
try:
    import gtksourceview
    
except:
    try:
        import gtksourceview2 as gtksourceview
    except:
        print 'No gtksourceview import possible. Please install gtksourceview for python!!'
        GtkSV = False

um dann später im Quellcode entsprechend unterschiedliche Funktionen abhängig von der Var GtkSV aufzurufen. Das ist einfach ätzend.

Hyperion hat geschrieben: Aber dann musst Du doch diese Bundles pflegen!? Ist das nicht vom Aufwand identisch?

Keinesfalls - wenn ich ein Bundle fertig habe, brauche ich die nächsten 10 jahre nichts mehr daran machen. Mein Programm benötigt nicht immer die neusten Versionen, sondern eine stabile Umgebung.

Hyperion hat geschrieben: Für die Installation solltest Du doch mittels `distribute` ein Paket zusammenstellen können, welches alle Abhängigkeiten (und da die kompatiblen Versionen) berücksichtigt. Wenn Du das dann Client seitig in einer `virtualenv`-Umgebung installierst, sehe ich da ehrlich gesagt nicht die von Dir ausgemalten Schwierigkeiten...

Nun ja, wie ich gesagt habe, das Pflegen der unterschiedlichen Module und python-Versionen kostet mich mehrere 100 Arbeitsstunden jedes Jahr, ich erhoffe mir einfach, das ich da gewaltig was sparen kann, sowohl im Programmierbereich wie auch im Installationsbereich.

Tschüss
Jürgen

lunar · Samstag 12. Mai 2012, 13:53

@jhamel: Mit verschiedenen Distributionen hat das nichts zu tun, sondern lediglich mit unterschiedlichen, teils inkompatiblen Versionen einzelner Module.

PIL sollte man nicht per "import Image" importieren, sondern ausschließlich per "from PIL import Image", so wie es in der Dokumentation empfohlen ist. Wenn das nicht funktioniert, dann ist die PIL-Version steinalt, was bei PIL wirklich was heißt. In jedem Fall solltest die Reihenfolge umkehren, denn "from PIL import Image" ist die neuere Variante, und in Zukunft irgendwann auch mal die einzige.

Und wieso der Versuch, "gtksourceview" zu importieren? Es sollte eigentlich nur "gtksourceview2" geben.

Die Paketnamen musst Du nur einmal heraussuchen, und anschließend einfach nur dokumentieren. Ansonsten kannst Du mit dem OBS wie gesagt auch Pakete für verschiedene Distributionen bauen.

Deine Idee vergiss aber besser wieder. Zwar kannst Du auch für Linux manuell oder mit pyinstaller eigenständige Pakete erzeugen, doch die sind nicht für die Ewigkeit, nicht mal vor zehn oder auch nur zwei Jahre, da gerade der Desktop unter Linux beständigen Veränderungen unterworfen ist, durch Standardisierungen, Technologien, die kommen und gehen, usw.

Durch die diverse Struktur von Linux-Distributionen ist es ohnehin nicht so einfach, eigenständige Pakete zu schnüren. Die hohe Integration von Anwendungen auf einem Linux-Desktop setzt voraus, dass es immer nur eine Version der darunter liegenden Bibliotheken gibt, sprich nur eine Gtk-Version, nur eine GVFS-Version, usw. Lieferst Du Deine eigenen Versionen dieser Bibliotheken mit, dann funktionieren diverse Plugins in Deiner Anwendung nicht, inklusive Themen oder GVFS-Modulen. Deine Anwendung sieht dann fremd aus, weil sie das vom Benutzer gewählte Theme nicht laden kann, und integriert sich nicht in das System, weil Plugins zum Zugriff auf Audioausgabe, Dateisystemabstraktionen, usw. fehlen. Dieses Phänomen lässt sich in diversen proprietären Linux-Anwendungen beobachten, die ebenfalls alle möglichen Bibliotheken in eigenen Versionen mitliefern.

jhamel · Samstag 12. Mai 2012, 15:27

lunar hat geschrieben: PIL sollte man nicht per "import Image" importieren, sondern ausschließlich per "from PIL import Image", so wie es in der Dokumentation empfohlen ist. Wenn das nicht funktioniert, dann ist die PIL-Version steinalt, was bei PIL wirklich was heißt. In jedem Fall solltest die Reihenfolge umkehren, denn "from PIL import Image" ist die neuere Variante, und in Zukunft irgendwann auch mal die einzige.

Und wieso der Versuch, "gtksourceview" zu importieren? Es sollte eigentlich nur "gtksourceview2" geben.

Genau das ist eins der Probleme. Da mein Programm teilweise vor 6 oder 8 Jahren Installiert worden ist, muß es auch auf solchen Rechnern problemlos weiter laufen.(Da hieß es eben noch gtksourceview). Das Programm selbst wird über den dazugehörigen Server aktualisiert. Da das im usermode ohne admin Rechte geschieht, bleiben alte python Installationen im System. Ich will auch nicht irgendwelche Systemweite python Sachen erneuern. Z.B. eine alte Ubuntu "Dapper Drake" Installation, da ist eben noch alles sehr alt.

Ist es richtig, das ich meine idee also OS bezogen verwirklichen kann ? Alle anderen Vorschläge habe ich schon für mein Programm vor Jahren verworfen.
Es ist leider so, das in Python ein ungeheurer Wildwuchs entstanden ist und auf der anderen Seite es für mich sehr viel einfacher wäre, wenn ich wenigsten im gewissen Rahmen einheitliche libs vorrausetzen kann.

Tschüss
Jürgen

lunar · Samstag 12. Mai 2012, 16:13

@jhamel: Ich glaube nicht, dass Du in diesem Forum noch irgendjemanden finden wirst, der noch Erfahrung darin hat, für sechs oder gar acht Jahre alte Linux-Systeme zu entwickeln, insofern kannst Du eine definitive Antwort auf die Frage, ob sich Deine Idee umsetzen lässt, nur durch eigene Experimente erhalten. Ich selbst würde pauschal verneinen.

Ein Linux-Desktop von vor sechs Jahren lässt sich mit einem heutigen kaum noch vergleichen. Was es damals schon gab, ist heute ganz anders. Heute gibt es direktes Rendering und Compositing, PulseAudio statt arts und esd, udisks und upower anstelle von HAL, DBus statt dcop und bonobo, Qt4 statt Qt3, usw. Auch das System selbst war komplett anders, es gab noch kein udev und devtmpfs, keine cgroups, wahrscheinlich noch gcc 3.3 und glibc 2.5 oder so, usw. Zudem gibt es heute vieles, was es damals gar nicht gab, wie Polkit, consolekit oder systemd, usw.

Selbst wenn Dein Programm nichts von alledem direkt benutzt, so tun es die Bibliotheken, auf die Dein Programm aufbaut, wie Gtk oder wohl diverse Gnome-Bibliotheken. Ich halte es für absolut unwahrscheinlich, dass eine Gtk-Bibliothek eines heutigen Systems auf einem System von vor sechs Jahren funktioniert, und umgekehrt. Du müsstest wahrscheinlich alle, und zwar wirklich alle Bibliotheken, die Dein Programm benutzt, selbst auf einem sechs Jahre alten System kompilieren, und selbst dann glaube ich nicht, dass die heutigen Quellen von Gtk auf einem so alten System kompilieren, oder - wenn doch - dieses Kompilat dann auf einem heutigen System läuft. In den letzten Jahren hat sich einfach zu viel geändert, sowohl an Binärschnittstellen zwischen Bibliotheken als auch im Bezug auf verschiedene Technologien und Protokolle, beispielsweise für das Sound-System oder IPC.

Wenn Du Dapper Drake unterstützen musst, dann ist die einzig sinnvolle Alternative, einen eigenen Entwicklungszweig für derart alte Versionen zu eröffnen, und Dein Programm dort gezielt daran anzupassen. Ich persönlich würde die Unterstützung einstellen, und dem Kunden dringend anraten, seine Systeme zu aktualisieren. Drapper Drake wird ja nicht einmal mehr von Canoncial unterstützt, ich kann kaum glauben, dass das noch irgendjemand kennt.

Im Übrigen hat das alles auch weniger mit Python selbst zu tun, die Sprache und ihre Standardbibliothek ist in den vergangenen sechs Jahren (also von Python 2.4 zu 2.7) weitestgehend kompatibel geblieben. Ein Python 2.4-Programm läuft in der Regel unverändert auch auf Python 2.7. Dein Problem sind die zu unterstützenden Systeme, die bezüglich ihrer Technologien und Schnittstellen einfach viel zu weit auseinander liegen.

jerch · Samstag 12. Mai 2012, 16:19

Bei so langen Supportzyklen für ein Programm, dessen Funktionalität nicht mehr angefasst wird, lohnt unter Linux vllt. der Einsatz einer VM. Spätestens nach ein bis zwei Major-Releases der glibc wirds sehr schwierig, ohne Neukompilieren oder Ändern der Programmabhängigkeiten durch Einsatz neuerer Modul- und Interpreterversionen den Support aufrecht erhalten zu können. Bei letzterem sind aber meist größere Eingriffe in den Code vorprogrammiert, da sich die Modul-APIs höchstwahrscheinlich geändert haben und Du in das von Dir beschriebene Problem läufst, mehrere Versionen parallel verwalten zu müssen.

Mein Vorschlag wäre daher, liefere das Programm in 3 Versionen aus:
- Standardversion, welche "nativ" auf modernen Linux-Distributionen läuft
- Windowsversion als Virtualenv-Container oder .exe
- VM-Version für alte Linuxinstallationen, die die Standardversion nicht mehr ausführen können

Vorteil dieses Ansatzes ist, das Du alle 3 Versionen mit dem selben Programm und dessen Abhängigkeiten ausstatten kannst, entsprechend geringen Bugfix-Aufwand hast und den Ärger mit zig parallelen Versionen sparst.
Nachteil sind der Aufwand für die VM-Pflege und Einschränkungen in der Benutzbarkeit auf Anwenderseite (evtl. ein k.o.-Kriterium).

Je nach Anteil der alten/neuen Distributionen auf Anwenderseite wären evtl. Standard- und VM-Version zu tauschen.

jhamel · Samstag 12. Mai 2012, 17:27

@alle Erstmal vielen Dank für die Antworten. Ich habe die Problematik ein wenig zu einfach dargestellt, deshalb ist es evtl. zu Verständnisproblemen gekommen.

jerch hat geschrieben:Bei so langen Supportzyklen für ein Programm, dessen Funktionalität nicht mehr angefasst wird,...

Das Programm wird seit 10 Jahren entwickelt und vorraussichtlich noch weitere 10 Jahre weiterentwickelt. Die Verteilung der neuen Programmversionen ( 100% python code) erfolgt über eigene Server.

jerch hat geschrieben: Mein Vorschlag wäre daher, liefere das Programm in 3 Versionen aus:
- Standardversion, welche "nativ" auf modernen Linux-Distributionen läuft
- Windowsversion als Virtualenv-Container oder .exe
- VM-Version für alte Linuxinstallationen, die die Standardversion nicht mehr ausführen können

Genau hier liegt mein Problem, der Aufwand ist enorm und ich muß das alles kostenlos machen, es ist ein GPL Programm. Ich hatte gehofft, mit python eine standartisierte Umgebung zu bekommen, aber leider ist das nicht der Fall. Eine VM-Umgebung kommt nicht in Frage, da das Programm dann zu sehr eingeschränkt wäre. Also finde ich die Idee einer lokalen Python Installation sehr interessant, z.B. unter http://isezen.com/2011/09/02/how-to-ins ... directory/. Das heißt also, wenn ich das mit WindowsXP und 7 machen kann, ebenso mit 2 oder 3 alten Linux-Versionen, wäre mir sehr geholfen. Für native Linux-Unterstützung gibt es .deb, rpm und tgz files. Wenn es allerdings funktioniert, würde ich es natürlich versuchen, das überall zu machen. Faktisch gesehen eine kleine "chroot" Umgebung für die Python-Umgebung, die den Python-Interpreter(z.B. 2.6.4) und pygtk, PIL, etc beinhaltet, kompiliert auf WindowsXP, Win/, Linux x86_64, linux i686, evtl. ein oder 2 ältere Linux Versionen, falls das erforderlich wäre.
I will also nicht mein Programm als Exe haben oder als bestimmte Version, sondern die Python-Umgebung soll standardisiert werden, so das z.B. mein Programm in 6 Jahren ohne Problem auf einen linux Rechner mit Python3 immer noch mit Python 2.6.4 läuft.

Deshalb war meine Frage hier ans Forum, ob evtl. einer Erfahrung damit hat.

Tschüss
Jürgen

jerch · Samstag 12. Mai 2012, 18:23

Du läufst mit Deinen Vorstellungen über Supportzyklen da leider völlig konträr zum Opensource/Linux-Entwicklungsmodell. So wird unter Linux der Einsatz von shared libs gegenüber dem Windowsmodell einer stark auf Abwärtskompatibilität gerichteten Grundkompomente (Win-API und Ausliefern aller Zusatzkomponenten mit der Applikation) bevorzugt. Eine derart standardisierte Grundkomponente gibt es unter Linux nicht, evtl. könnte man hier noch die syscalls oder eine Ebene höher die glibc verorten, beides (auch der Kernel) unterliegt selbst aber wiederum einer hohen Dynamik. Für kommerzielle Anbieter wird das schnell zur Supportfalle. Wenn dann noch Dinge wie Desktopintegration oder Soundsupport hinzukommen, wird es unter Linux sehr bunt und die Bibliothekenlandschaft riesig (zum Glück gibts Bestrebungen der bibliotheksübergreifenden Standardisierung). Einem Windows-Entwickler können solche Probleme nur ein müdes Lächeln abringen, die WinAPI sorgt für Persistenz.

Aus diesem Umfeld kommt CPython und unterliegt daher auch dieser Dynamik. Es ist leider hanebüchen zu glauben, dass Dein Programm selbst mittels Virtualenv, selbstkompilierten und gegen alte Syslibs gelinkten Libs etc. noch in 10 Jahren rückportierbar ist. Spätestens mit Änderung des ABI (warum auch immer - z.B. Änderungen in ELF, gcc/linker, glibc, syscalls) ist der Spaß vorbei, ganz zu schweigen vom Aufwand, hinzugewonnene Features durch neuere Modulversionen rückportieren zu müssen. Mit Python3 hängt das Damokles-Schwert schon über Python selbst, wenn auch noch an einem sehr dicken Faden

Ist es da nicht einfacher, sich der Dynamik anzunehmen und alte Versionen der Applikation auslaufen zu lassen? Sollten dem lange Supportverträge im Wege stehen, ist das mit einem Feature-Freeze und Beschränkung auf Bugfixes zu erreichen. Die Einschränkung auf neuere Versionen kannst Du dabei recht einfach über die Pythonversion erreichen, ernsthafte Drittmodule, die ihr einsetzt, sollten diese berücksichtigen. Insofern liefert Python Dir durchaus eine gewisse Standardisierung.

BlackJack · Samstag 12. Mai 2012, 19:12

@jhamel: „[…], der Aufwand ist enorm und ich muß das alles kostenlos machen, es ist ein GPL Programm.”

Ich hoffe die GPL dient hier nicht als Begründung es kostenlos machen zu müssen. Die Lizenz schliesst ja nicht aus, dass man Geld verlangen darf.

jhamel · Samstag 12. Mai 2012, 21:15

jerch hat geschrieben:Du läufst mit Deinen Vorstellungen über Supportzyklen da leider völlig konträr zum Opensource/Linux-Entwicklungsmodell. So wird unter Linux der Einsatz von shared libs gegenüber dem Windowsmodell einer stark auf Abwärtskompatibilität gerichteten Grundkompomente (Win-API und Ausliefern aller Zusatzkomponenten mit der Applikation) bevorzugt. Eine derart standardisierte Grundkomponente gibt es unter Linux nicht, evtl. könnte man hier noch die syscalls oder eine Ebene höher die glibc verorten, beides (auch der Kernel) unterliegt selbst aber wiederum einer hohen Dynamik. Für kommerzielle Anbieter wird das schnell zur Supportfalle. Wenn dann noch Dinge wie Desktopintegration oder Soundsupport hinzukommen, wird es unter Linux sehr bunt und die Bibliothekenlandschaft riesig (zum Glück gibts Bestrebungen der bibliotheksübergreifenden Standardisierung). Einem Windows-Entwickler können solche Probleme nur ein müdes Lächeln abringen, die WinAPI sorgt für Persistenz.

Aus diesem Umfeld kommt CPython und unterliegt daher auch dieser Dynamik. Es ist leider hanebüchen zu glauben, dass Dein Programm selbst mittels Virtualenv, selbstkompilierten und gegen alte Syslibs gelinkten Libs etc. noch in 10 Jahren rückportierbar ist. Spätestens mit Änderung des ABI (warum auch immer - z.B. Änderungen in ELF, gcc/linker, glibc, syscalls) ist der Spaß vorbei, ganz zu schweigen vom Aufwand, hinzugewonnene Features durch neuere Modulversionen rückportieren zu müssen. Mit Python3 hängt das Damokles-Schwert schon über Python selbst, wenn auch noch an einem sehr dicken Faden

Ist es da nicht einfacher, sich der Dynamik anzunehmen und alte Versionen der Applikation auslaufen zu lassen? Sollten dem lange Supportverträge im Wege stehen, ist das mit einem Feature-Freeze und Beschränkung auf Bugfixes zu erreichen. Die Einschränkung auf neuere Versionen kannst Du dabei recht einfach über die Pythonversion erreichen, ernsthafte Drittmodule, die ihr einsetzt, sollten diese berücksichtigen. Insofern liefert Python Dir durchaus eine gewisse Standardisierung.

Hallo, danke für deine ausführliche Antwort, und ich habe mich bestimmt wieder mal sehr missverständlich ausgedrückt, sorry. Es geht nicht um alte Versionen meines Programmes, sondern um alte Python- und Modulversionen und die Schwierigkeiten mit dem Updaten dieser Versionen. Diese können vielfäliger Natur sein, keine root rechte, kein Modul in der Paketverwaltung, verschieden alte/neue Versionen. Dieses Beispiel soll nicht abwertend sein, ist aber sehr realistisch: Wie soll ich einer 58 jährigen, mir fremden Mitarbeiterin einer mir fremden Firma in Lettland ohne English und Computer Kenntnisse erklären, das auf Ihren PC ein bestimmtes python-Modul installiert werden soll ? Mein Programm wird selbständig über den Server aktualisiert, die einzige nötige interaktion ist einen OK button drücken. Leider gibt es dann Probleme, wenn ich bestimmte Routinen in der neuen Version nutze, die evtl. nicht auf dem Benutzer-Rechner installiert sind.

Deine Einwände nehme ich selbstverständlich sehr ernst, aber inzwischen gibt es einen Hoffnungsschimmer. Vor 1 Jahr habe ich mal Experimente mit Portable Python http://portablepython.com/wiki/WikiStart gemacht, das ich auf einen USB Stick benutzte. Allerdings versuchte ich viel zu viel damals, mit OpenOffice, Thunderbird, usw. Jetzt erinnerte ich mich daran und es erscheint mir evtl. schon mal als Lösung für die Windows-Reihe. Ich muß das natürlich erstmal in den nächsten Wochen antesten.

Also, um zur Linux Version zurückzukommen, dein Einwand bezieht sich auf meine missverständliche Ausdrucksweise. Ich möchte z.B. einfach ein python mit alles benötigten Modulen im cuon-user-Verzeichnis auf einen Lucid Lynx Rechner aufsetzen. Die Abi würde sich meiner Meinung nach nicht ändern, auch nach 7 Jahren nicht. Ich möchte also z.B. ein Python 2.7.3.1 auf den Windows-Rechner, auf Lucid-Lynx, auf Debian Squeeze, auf Suse 11.2 lokal installiert haben. z.B. ich kompiliere python unter SuSE 11.2 mit der configure option

Code: Alles auswählen

 make altinstall prefix=~/cuon/usr/local exec-prefix=~/cuon/usr/local

. Hauptsächlich wollte ich wissen, ob es genügt, das ganze für die Architektur zu machen. Deinen Äußerungen zufolge muß ich es aber wahrscheinlich für jede Distributions-Version machen, oder ?

Für mich ergibt sich damit eine sehr große Stabilität im Enwicklungszyklus und ich muß nicht immer drauf achten, ob plötzlich Sachen von 2.6 nach 2.7 nicht mehr funktionieren, einfache grundlegende Kommandos plötzlich Fehler schmeißen. Ich hätte auf allen Zielplatformen die gleiche python-Version, die gleichen Module, etc.

Tschüss
Jürgen

Hyperion · Samstag 12. Mai 2012, 21:44

Ich glaube, Du hast lunars Posting nicht verstanden oder gelesen! Ich verweise speziell noch mal auf den dritten Absatz.

Du könntest natürlich einfach mit den alten Versionen arbeiten als kleinsten gemeinsamen Nenner. Allerdings beißt Du Dich dann anders herum in den Schwanz: Auf neuen Systemen laufen alte Libs auch nicht so einfach und selbstverständlich.

Ich denke eine vernünftige Lösung via "distutils/setuptools" ist die einfachste, robuste Lösung; alles andere führt nur zu anderen, imho schwerer zu handhabenden Problemen.

Eine Installationsanleitung für eine Standardvorgehensweise ist sicherlich leichter zu schreiben als für eine selbst gebastelte, untypische Methode. Zudem können Fehler mit ersterem leichter behoben werden - da hilft alleine schon die Masse an Benutzern, die so vorgehen.

Wenn Du Benutzer hast, die dermaßen unversiert sind, dann ist eine native Client-Anwendung immer problematisch! Daher sicherlich auch der Hype um Webapplikationen - da braucht es keine Installation mehr

Einen universellen, Dau mäßigen Weg, eine neue Software auf einem x beliebigen System zu installieren, gibt es einfach nicht.

lunar · Sonntag 13. Mai 2012, 00:34

@jhamel: Du kannst Python durchaus lokal im Benutzerverzeichnis installieren, und diese Umgebung dann zur Entwicklung nutzen. Du kannst sie allerdings nicht an Kunden ausliefern, deren Systeme sich stark von Deinem unterscheiden, weil sie wesentlich älter oder wesentlich neuer sind, aus den erwähnten Gründen: An irgendeinem Punkt muss Dein Programm mit dem System kommunizieren, und sei es nur, um indirekt (über Gtk) auf die Bildschirmausgabe zuzugreifen und Tastatureingaben zu lesen. Und selbst bei derart grundlegenden Dingen hat sich Linux in den vergangenen sechs Jahren verändert... und es wird sich auch in den kommenden sechs Jahren verändern, so dass Du ein Programm, welches Du heute kompilierst, in sechs Jahren kaum auf einem dann aktuellen Linux-System zum Laufen bringen wirst.

jerch · Sonntag 13. Mai 2012, 03:32

jhamel hat geschrieben:Hallo, danke für deine ausführliche Antwort, und ich habe mich bestimmt wieder mal sehr missverständlich ausgedrückt, sorry. Es geht nicht um alte Versionen meines Programmes, sondern um alte Python- und Modulversionen und die Schwierigkeiten mit dem Updaten dieser Versionen. Diese können vielfäliger Natur sein, keine root rechte, kein Modul in der Paketverwaltung, verschieden alte/neue Versionen. Dieses Beispiel soll nicht abwertend sein, ist aber sehr realistisch: Wie soll ich einer 58 jährigen, mir fremden Mitarbeiterin einer mir fremden Firma in Lettland ohne English und Computer Kenntnisse erklären, das auf Ihren PC ein bestimmtes python-Modul installiert werden soll ? Mein Programm wird selbständig über den Server aktualisiert, die einzige nötige interaktion ist einen OK button drücken. Leider gibt es dann Probleme, wenn ich bestimmte Routinen in der neuen Version nutze, die evtl. nicht auf dem Benutzer-Rechner installiert sind.

Ich hab das schon so verstanden, dass Du neue Versionen des Programmes gerne auf 10 Jahre alten Linuxversionen laufen lassen möchtest. Das ist ja gerade das Problem.

Vllt hilft Dir zum Verständnis des Problemes die Analyse dessen, was Du von Deinem Programm preisgegeben hast:
- Dein Programm ist in Python geschrieben. Ok - Grundabhängigkeit des Programmes ist ein funktionierender Python-Interpreter. Dieser ist im Falle von CPython gelinkt gegen (auf Suse 11.4):

Code: Alles auswählen

~> ldd /usr/bin/python
        linux-vdso.so.1 =>  (0x00007fff26164000)
        libpython2.7.so.1.0 => /usr/lib64/libpython2.7.so.1.0 (0x00007f2473860000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f2473643000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f247343f000)
        libutil.so.1 => /lib64/libutil.so.1 (0x00007f247323c000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f2472fe5000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f2472c78000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f2473c08000)

- Hinzu kommt das Gtk-Modul, unter Suse 11.4:

Code: Alles auswählen

~> ldd /usr/lib64/python2.7/site-packages/gtk-2.0/gtk/_gtk.so
        linux-vdso.so.1 =>  (0x00007fff72fff000)
        libgtk-x11-2.0.so.0 => /usr/lib64/libgtk-x11-2.0.so.0 (0x00007f816ff98000)
        libgdk-x11-2.0.so.0 => /usr/lib64/libgdk-x11-2.0.so.0 (0x00007f816fce3000)
        libgio-2.0.so.0 => /lib64/libgio-2.0.so.0 (0x00007f816f9b4000)
        libgdk_pixbuf-2.0.so.0 => /usr/lib64/libgdk_pixbuf-2.0.so.0 (0x00007f816f795000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f816f53e000)
        libcairo.so.2 => /usr/lib64/libcairo.so.2 (0x00007f816f285000)
        libpango-1.0.so.0 => /usr/lib64/libpango-1.0.so.0 (0x00007f816f039000)
        libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x00007f816ede8000)
        libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00007f816eaf5000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f816e8d8000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f816e56b000)
        libpangocairo-1.0.so.0 => /usr/lib64/libpangocairo-1.0.so.0 (0x00007f816e35d000)
        libX11.so.6 => /usr/lib64/libX11.so.6 (0x00007f816e01a000)
        libXfixes.so.3 => /usr/lib64/libXfixes.so.3 (0x00007f816de14000)
        libatk-1.0.so.0 => /usr/lib64/libatk-1.0.so.0 (0x00007f816dbf1000)
        libpangoft2-1.0.so.0 => /usr/lib64/libpangoft2-1.0.so.0 (0x00007f816d9c4000)
        libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 (0x00007f816d78d000)
        libgmodule-2.0.so.0 => /lib64/libgmodule-2.0.so.0 (0x00007f816d588000)
        libXext.so.6 => /usr/lib64/libXext.so.6 (0x00007f816d375000)
        libXrender.so.1 => /usr/lib64/libXrender.so.1 (0x00007f816d16a000)
        libXinerama.so.1 => /usr/lib64/libXinerama.so.1 (0x00007f816cf66000)
        libXi.so.6 => /usr/lib64/libXi.so.6 (0x00007f816cd56000)
        libXrandr.so.2 => /usr/lib64/libXrandr.so.2 (0x00007f816cb4d000)
        libXcursor.so.1 => /usr/lib64/libXcursor.so.1 (0x00007f816c941000)
        libXcomposite.so.1 => /usr/lib64/libXcomposite.so.1 (0x00007f816c73e000)
        libXdamage.so.1 => /usr/lib64/libXdamage.so.1 (0x00007f816c53b000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f816c323000)
        libz.so.1 => /lib64/libz.so.1 (0x00007f816c10b000)
        libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f816beec000)
        libpixman-1.so.0 => /usr/lib64/libpixman-1.so.0 (0x00007f816bc7c000)
        libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00007f816b9f2000)
        libpng14.so.14 => /usr/lib64/libpng14.so.14 (0x00007f816b7c8000)
        libgthread-2.0.so.0 => /lib64/libgthread-2.0.so.0 (0x00007f816b5c2000)
        libpcre.so.0 => /lib64/libpcre.so.0 (0x00007f816b38c000)
        librt.so.1 => /lib64/librt.so.1 (0x00007f816b183000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f8170aa8000)
        libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00007f816af65000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f816ad61000)
        libexpat.so.1 => /lib64/libexpat.so.1 (0x00007f816ab36000)
        libXau.so.6 => /usr/lib64/libXau.so.6 (0x00007f816a931000)

WTF - schon an dieser Stelle wird klar, was da im Hintergrund an Abhängigkeiten existiert. Das wird vom Distributor schön versteckt, in dem dieser Dir das Paket fertig verpackt ausliefert. Nichtsdestotrotz "lebt" das Modul von diesen Abhängigkeiten, da es deren Grundfunktionalität in nifty Pythoncode verpackt und Dir zur weiteren Benutzung zur Verfügung stellt.
Mit jedem weiteren benutzten Modul, welches nicht "pure python" ist, werden diese Abängigkeiten ins C-Land größer. Was, wenn auch nur ein Lib-Maintainer die Spec ändert? Ist das unrealistisch in 10 Jahren?
Zusätzlich hierzu unterliegen die Pythonmodule selbst einer Entwicklung und API-Changes.

Und jetzt überlegen wir mal, was wir da vor 10 Jahren hatten (nicht recherchiert und daher mitunter fehlerhaft):
- glibc 2.2 - heute 2.15 (mehrfache API changes)
- Python um 2.0 - heute 2.7 und 3.2
- gtk frühe 2er Version, viele fehlende Widgets zu heute (kein Cairo, kein DBus etc), heute 3.4
- XFree86 4.2, heute vom "alten" X11 wieder abgelöst X11R7.6
Und da alles in C ist, noch der gcc zum Vergleich: 2002 3.0/3.1, heute 4.6+

Das alles wäre kein Problem, wenn sich nicht auch Dinge wie glibc und gcc grundlegend geändert hätten. Dann würde das Kompilieren gegen alte Systemlibversionen weiterhin funktionieren und nur den Aufwand bedeuten, gtk und Konsorten dagegen zu linken. Dem ist aber nicht so und auch in Zukunft werden die grundlegenden Build-Tools/Sys-Libs nicht stehenbleiben. Zwar werden diese relativ konservativ gehandhabt (im Sinne der Linux-Dynamik) und Distributoren versuchen auch, die Unterschiede über einige Distributionsversionen hinweg aufzufangen. Allerdings liegt ein Supportzyklus von 8+ Jahren jenseits dessen, was ich unter Linux je gesehen habe. Unterm Strich heisst das für Dich, dass ein 'make altinstall ...' einer zukünftigen Pythonversion ab Zeitpunkt X schlicht und ergreifend nicht mehr funktioniert.

Für geringe Unterschiede zwischen den Distributionen ist das Deployment über eine lokale Installation durchaus gangbar. Auf einem SuSE 6.0 wirst du allerdings Dein Programm nicht mehr zur Mitarbeit überreden können, da die Unterschiede selbst mit hohem Aufwand nicht mehr überbrückbar sind.

problembär · Sonntag 13. Mai 2012, 15:34

lunar hat geschrieben:Ein Linux-Desktop von vor sechs Jahren lässt sich mit einem heutigen kaum noch vergleichen. Was es damals schon gab, ist heute ganz anders. Heute gibt es direktes Rendering und Compositing, PulseAudio statt arts und esd, udisks und upower anstelle von HAL, DBus statt dcop und bonobo, Qt4 statt Qt3, usw. Auch das System selbst war komplett anders, es gab noch kein udev und devtmpfs, keine cgroups, wahrscheinlich noch gcc 3.3 und glibc 2.5 oder so, usw. Zudem gibt es heute vieles, was es damals gar nicht gab, wie Polkit, consolekit oder systemd, usw.

In der Tat, damit (und mit den meisten genannten neuen Auto-Komponenten wie udev und HAL) kämpfe ich auch gerade.
Ich hab' sogar 'ne VM mit Virtualbox und SuSE 8.1 aufgesetzt, weil ein altes ClosedSource-Programm sonst beim besten Willen nicht zum Laufen zu bringen war. Das geht recht gut, und sofern Virtualbox Bestand hat, könnte das auch für die Ewigkeit so gehen.
Aber natürlich ist es für ein GPL-Projekt keine Option, immer gleich eine komplette VM anzubieten. Mein SuSE 8.1 frißt ja auch schon fast 1GB.
Ich habe hier immer gesagt, man sollte möglichst altbewährte Python-Syntax nutzen und möglichst wenig Module einsetzen.
Und bin dafür angefeindet worden.
jhamel, Du hast Dich von anderen abhängig gemacht und darfst ihnen nun immer hinterherlaufen. Das tut mir leid.
Da es ein GPL-Projekt ist und Dir niemand etwas dafür bezahlt, könntest Du das Projekt einstellen, wenn's Dich zu sehr nervt. Das wäre schade, aber diese Fortschrittsfanatiker lassen Dir wahrscheinlich keine Wahl.
Für Qt3 z.B. gab es eine ganze Masse an Programmen. Mit Qt4 hat man Qt3 einfach komplett fallengelassen, alles bei Null wieder angefangen, und manchmal, bei kmail2, ist es sogar bei Null geblieben. Man hat da sehr viele Programmierer im Regen stehen lassen. Du bist da nicht der einzige. Wenn Dich das etwas tröstet ...

Hyperion · Sonntag 13. Mai 2012, 15:54

problembär hat geschrieben: Da es ein GPL-Projekt ist und Dir niemand etwas dafür bezahlt, könntest Du das Projekt einstellen, wenn's Dich zu sehr nervt.

BlackJack hatte es schon einmal gesagt: Die GPL hat *nichts* mit irgend einer Bezahlung zu tun!

problembär hat geschrieben: Für Qt3 z.B. gab es eine ganze Masse an Programmen. Mit Qt4 hat man Qt3 einfach komplett fallengelassen, alles bei Null wieder angefangen, und manchmal, bei kmail2, ist es sogar bei Null geblieben. Man hat da sehr viele Programmierer im Regen stehen lassen. Du bist da nicht der einzige. Wenn Dich das etwas tröstet ...

Du verwechselst einige Dinge bzw. stellst sie ungenau dar. Qt3 ist ja nicht einfach verschwunden! Ganz im Gegenteil ist das durchaus ein Beispiel für eine Lib, die sogar heute noch, zig Jahre nach dem Start von Qt4, auf modernen Systemen verfügbar ist. Ich weiß nicht aus dem Kopf, wie lange Trolltech seinerzeit noch Qt3 maintained hat, *nachdem* Qt4 bereits final vorlag. Mit Sicherheit einige Zeit lang.

`KMail` ist nun wieder etwas komplett anderes. Das hat mit Qt nichts zu tun, sondern ist ein Programm aus der PIM-Suite von KDE. Und wieso hat man da "Programmierer" im Regen stehen lassen? Das würde mich da doch mal interessieren...

Generell ist es so, dass Libs nun mal auf Dauer "sterben", wenn es eine neue Major-Version gibt. Die Dauer des "Sterbens" hängt sicherlich auch davon ab, wie lange wichtige Programme noch auf die alte Version setzen. Wie Du an Qt3 erkennen kannst, scheint dieses Framework doch ziemlich stark verbreitet (gewesen) zu sein.

BlackJack · Sonntag 13. Mai 2012, 15:59

@problembär: Das ist nicht „altbewährte Python-Syntax” sondern Idiome aus anderen Programmiersprachen in Python-Syntax gepresst, was Du hier immer wieder ablieferst. Umständlicher ausgedrückt als es sein müsste und damit schwerer verständlich und fehleranfälliger. Was kombiniert mit der „ich erfinde das Rad lieber selber”-Einstellung, anstatt Module aus der Standardbibliothekt zu verwenden, nicht besser wird.

Deine Behauptungen zu Qt3→Qt4 sind entweder dreist gelogen, oder Du weisst (mal wieder) nicht wovon Du sprichst. Qt4 hat nicht komplett von Null angefangen. Die Grundkonzepte sind im Wesentlichen gleich geblieben und es gab zum Übergang eine Kompatibilitätsbibliothek und ein Werkzeug ``qt3to4``, was bei der Portierung unterstützt hat. Mindestens in Ubuntu 10.04 LTS ist auch Qt3 inklusive aller Werkzeuge wie der Designer und auch das `libqt4-qt3support`-Paket noch enthalten.

jerch · Sonntag 13. Mai 2012, 21:17

problembär hat geschrieben:jhamel, Du hast Dich von anderen abhängig gemacht und darfst ihnen nun immer hinterherlaufen. Das tut mir leid.
Da es ein GPL-Projekt ist und Dir niemand etwas dafür bezahlt, könntest Du das Projekt einstellen, wenn's Dich zu sehr nervt. Das wäre schade, aber diese Fortschrittsfanatiker lassen Dir wahrscheinlich keine Wahl.

Was soll diese Polemik? Du kannst durchaus 1000€ für eine Stunde Deiner Programmierkunst verlangen und das Ergebnis trotzdem in GPL abliefern. Das nennt sich Vertragsfreiheit und gerade der Punkt der Entlohnung ist nicht Gegenstand der GPL. (vgl. free as in beer/free as in speech)
Zum Glück teilen nur wenige die Einstellung Deines letzten Satzes, sonst dürften wir immer noch Mammuts jagen.

BlackJack · Sonntag 13. Mai 2012, 21:43

@jerch: Mammuts erfordern Werkzeuge, die nicht zur Standardbibliothek eines Menschen gehören. Was man nicht mit blossen Händen um die Ecke bringen kann ist viel zu fortschrittlich. SCNR