Hi, ich möchte eine kleine Anwendung schreiben, die ohne Installation auf Win32, Linux und OS-X läuft. Die benötigten (GUI-) Bibliotheken sollen auch in dem stand-alone-Executable enthalten sein. Sprich: die Anwendung soll alles, was sie braucht, mitbringen, um Versionskonflikte zu vermeiden. Wie bekomme ich das für Windows hin? py2exe? Und für OS-X? (Da habe ich gar keinen Plan) Brauche ich da für's Entwickeln/Build einen Win/Mac-Maschine? Sorry, für die dummen Fragen, aber bislang habe ich imemr nur unter Unix/Linux entwickelt und das Zeug wurde dann installiert. Das ist einfacher :-) -- Schönen Gruß - Regards Hartmut Goebel Goebel Consult Spezialist für IT-Sicherheit in komplexen Umgebungen http://www.goebel-consult.de
Hartmut,
Wie bekomme ich das für Windows hin? py2exe? richtig. wx-Python in eine singuläre .exe zu packen ist möglich, aber etwas anstrengend.
Brauche ich da für's Entwickeln/Build einen Win/Mac-Maschine? für den Build und den Test brauchst Du ne Windows Maschine. wxPython ist zwar theorethisch Plattformunabhängig, aber cross plattform mit py2exe ein SingleFilePython zu erzeugen hat einige Kanten und Ecken.
Gruß Harald -- GHUM Harald Massa persuadere et programmare Harald Armin Massa Spielberger Straße 49 70435 Stuttgart 0173/9409607 no fx, no carrier pidgeon - EuroPython 2008 will take place in Vilnius, Lithuania - Stay tuned!
Hallo Harald,
richtig. wx-Python in eine singuläre .exe zu packen ist möglich, aber etwas anstrengend.
Wäre dann GTK, oder QT einfacher? (Habe habe dumemrweise auch kaum Erfahrung mit GUI-Programmierung :-) -- Schönen Gruß - Regards Hartmut Goebel Goebel Consult Spezialist für IT-Sicherheit in komplexen Umgebungen http://www.goebel-consult.de
On Fri, 20 Jun 2008 14:39:47 +0200 Hartmut Goebel <h.goebel@goebel-consult.de> wrote:
Wäre dann GTK, oder QT einfacher? (Habe habe dumemrweise auch kaum Erfahrung mit GUI-Programmierung :-)
So kompliziert ist das wx-Packan gar nicht. Als ich das vor einigen Jahren gemacht habe wars sogar recht einfach. py2exe und PyGTK spielen nicht so gut zusammen - es ist zwar möglich aber man muss DLLs von Hand mit reinnehmen etc. Qt habe ich nicht probiert zu packen. grüße, Marek
Marek Kubica schrieb:
So kompliziert ist das wx-Packan gar nicht. Als ich das vor einigen Jahren gemacht habe wars sogar recht einfach. py2exe und PyGTK spielen nicht so gut zusammen - es ist zwar möglich aber man muss DLLs von Hand mit reinnehmen etc. Qt habe ich nicht probiert zu packen.
Naja, wenn es sich darauf beschränkt, ein paar Dateien manuell aufzuführen, dann gaht das ja. Dann werde ich wohl doch wx Probieren. Danke. -- Schönen Gruß - Regards Hartmut Goebel Goebel Consult Spezialist für IT-Sicherheit in komplexen Umgebungen http://www.goebel-consult.de
Wie bekomme ich das für Windows hin? py2exe?
Denke schon, ja. Habe damit aber recht wenig Erfahrungen.
Und für OS-X? (Da habe ich gar keinen Plan)
Da heisst das tool py2app, bzw. das ist eine distutils-extension. Damit kannst du komplett self-contained sogenannte application bundles bauen - das ist das Aequivalent einer EXE.
Brauche ich da für's Entwickeln/Build einen Win/Mac-Maschine?
Denke schon - in der Theorie geht in der Praxis ja nix schief. Praktisch aber schon...
Sorry, für die dummen Fragen, aber bislang habe ich imemr nur unter Unix/Linux entwickelt und das Zeug wurde dann installiert. Das ist einfacher :-)
Noe, ist es nicht. Es hat dieselben Probleme. In mancher Hinsicht sogar mehr. Welche python-version ist installiert, musst/willst/kannst du paketmanagement nutzen, was ist mit 3rd-party-libs - sind die installiert, werden sie das, wenn ja in welchen versionen usw. Deployment suxors... Diez
Diez B. Roggisch schrieb:
Brauche ich da für's Entwickeln/Build einen Win/Mac-Maschine?
Denke schon - in der Theorie geht in der Praxis ja nix schief. Praktisch aber schon...
py2app: Nach meinen ersten Versuchen kann man zwar unter Linux ein Bundle bauen, aber natürlich ohne die Python.exe (bzw. app). py2exe: Braucht zwingend Windows zum Build. mac-millan-installer: schient auch "one-file" Pakete bauen zu können, habe ich aber noch nicht getestet.
Deployment suxors...
:-) :-\ -- Schönen Gruß - Regards Hartmut Goebel Goebel Consult Spezialist für IT-Sicherheit in komplexen Umgebungen http://www.goebel-consult.de
Hartmut Goebel:
ich möchte eine kleine Anwendung schreiben, die ohne Installation auf Win32, Linux und OS-X läuft. Die benötigten (GUI-) Bibliotheken sollen auch in dem stand-alone-Executable enthalten sein. Sprich: die Anwendung soll alles, was sie braucht, mitbringen, um Versionskonflikte zu vermeiden.
Wie bekomme ich das für Windows hin? py2exe? Und für OS-X? (Da habe ich gar keinen Plan) Brauche ich da für's Entwickeln/Build einen Win/Mac-Maschine?
Unter Mac OS X kann man viele sogenannte "Bundles" (Verzeichnisse für Anwendungen aller Art, z.B. ".app", ".saver", etc.) einfach mit "python setup.py py2app" erzeugen, ohne die ganzen Mac-typisch Ent- wicklungswerkzeuge wie Xcode und InterfaceBuilder. Aber ob das auch auf anderen Plattformen geht, wage ich zu bezweifeln. Überhaupt scheint mir Dein Wunsch etwas zu anspruchsvoll. ;-) Gruß, Dinu
Hartmut Goebel <h.goebel@goebel-consult.de> at Thursday 19 June 2008, 12:15:57
Hi,
ich möchte eine kleine Anwendung schreiben, die ohne Installation auf Win32, Linux und OS-X läuft. Die benötigten (GUI-) Bibliotheken sollen auch in dem stand-alone-Executable enthalten sein.
Zumindest unter Linux ist das eher unerwünscht ;) Wofür hat man den Paketmanagement.
Wie bekomme ich das für Windows hin? py2exe?
Ja, aber meine Erfahrungen mit Qt 4 waren eher abschreckend. Das Ganze ist sehr anstrengend, da py2exe es bei komplexeren Bibliotheken nicht hinkriegt, alle Abhängigkeiten zu packen.
Brauche ich da für's Entwickeln/Build einen Win/Mac-Maschine?
Die Frage solltest du dir selbst beantworten können: Wenn man eine Anwendung für ein System ausliefert, muss sich auch unter diesem System getestet werden. Alles andere ist fahrlässig. Ein Cross-Build ist mit py2exe + neueres wine zwar möglich, aber noch mal zwei Stufen ätzender als py2exe unter Windows ... Wenn ich noch ein paar persönliche Sachen anmerken darf: Imho ist es weniger stressig, die benötigten Pakete als Installer mitzuliefern. Bei distutils/setuptools-Projekten lassen sich diese Installer auch nachträglich bauen, wenn sie nicht existieren. Diese Installer kann man dann mit InnoSetup oder NSIS zusammenschalten, so dass sie hintereinander ausgeführt werden. Das ist zwar nicht ganz so komfortabel, spart aber einiges an Kopfschmerzen für dich als Programmierer. Und dem Windows-verwöhneten Setup.exe-Doppelklicker kannst du trotzdem einen einzigen Installer anbieten ... -- Freiheit ist immer die Freiheit der Andersdenkenden. (Rosa Luxemburg)
Sebastian Wiesner schrieb:
Brauche ich da für's Entwickeln/Build einen Win/Mac-Maschine?
Die Frage solltest du dir selbst beantworten können: Wenn man eine Anwendung für ein System ausliefert, muss sich auch unter diesem System getestet werden. Alles andere ist fahrlässig.
Das der Builder muss nicht gleich der Tester sein ;-) Im Gegenteil kann es für Test interessant sein, eine Maschine zu habe, auf der keine "Reste" einer Entwicklung-Umgebung sind.
einiges an Kopfschmerzen für dich als Programmierer. Und dem Windows-verwöhneten Setup.exe-Doppelklicker kannst du trotzdem einen einzigen Installer anbieten ...
Danke für den Tipp. Ich will aber eigentlich ganz ohne Installation auskommen :-) (Zu mindest momentan, vielleicht überlege ich mir das noch anders ;-) -- Schönen Gruß - Regards Hartmut Goebel Goebel Consult Spezialist für IT-Sicherheit in komplexen Umgebungen http://www.goebel-consult.de
Hartmut Goebel <h.goebel@goebel-consult.de> at Monday 23 June 2008, 09:34:40
Sebastian Wiesner schrieb:
Brauche ich da für's Entwickeln/Build einen Win/Mac-Maschine?
Die Frage solltest du dir selbst beantworten können: Wenn man eine Anwendung für ein System ausliefert, muss sich auch unter diesem System getestet werden. Alles andere ist fahrlässig.
Das der Builder muss nicht gleich der Tester sein ;-) Im Gegenteil kann es für Test interessant sein, eine Maschine zu habe, auf der keine "Reste" einer Entwicklung-Umgebung sind.
Klar, aber um die zusätzlichen Systeme kommst du eh nicht drumrum, dann kannst du auch gleich eine solche zum Bauen nutzen. Das hat den Vorteil, dass man sich die Kopfschmerzen beim Einrichten einer "Cross-Compilation-Toolchain" spart. py2exe unter wine war bei meinen Experimenten eher Abenteuer als produktives Arbeiten ;)
einiges an Kopfschmerzen für dich als Programmierer. Und dem Windows-verwöhneten Setup.exe-Doppelklicker kannst du trotzdem einen einzigen Installer anbieten ...
Danke für den Tipp. Ich will aber eigentlich ganz ohne Installation auskommen :-) (Zu mindest momentan, vielleicht überlege ich mir das noch anders ;-)
Gab es nicht iirc irgendwo ein portable Python? Darauf kannst du doch Aufbauen, es mit deinen benötigten Paketen erweitern und dann verteilen. Imho ist das immer noch schmerzloser als py2exe und pyinstaller. Das sind jetzt aber nur so Gedanken, wie man diese Tools vermeiden könnte, ich bin mit diesen nämlich nie richtig glücklich geworden ;) -- Freiheit ist immer die Freiheit der Andersdenkenden. (Rosa Luxemburg)
ich möchte eine kleine Anwendung schreiben, die ohne Installation auf Win32, Linux und OS-X läuft. Die benötigten (GUI-) Bibliotheken sollen auch in dem stand-alone-Executable enthalten sein. Sprich: die Anwendung soll alles, was sie braucht, mitbringen, um Versionskonflikte zu vermeiden.
Wie bekomme ich das für Windows hin? py2exe? Und für OS-X? (Da habe ich gar keinen Plan) Brauche ich da für's Entwickeln/Build einen Win/Mac-Maschine?
Es ist im Prinzip möglich (und mit entsprechender Übung auch gar nicht so schwer) auf allen Systemen einheitlich ein Executable mittels freeze zu erzeugen (*). Alle C-Module müssen builtin werden; alle Python-Module werden mittels freeze als frozen modules an das Executable herangelinkt. Wenn man das aber noch nie gemacht hat, wird man sicher etliche Tage brauchen, bis es funktioniert. Wenn man das dann geschafft hat, kann man im Prinzip auch auf die Win/Mac-Maschine verzichten, indem man den GCC als Cross-Compiler verwendet. Ist aber höllisch schwierig. Ich empfehle, die Ziele zu überdenken und doch eine Installationsprozedur zu erlauben. Ist echt viel einfacher. Ciao, Martin (*) also: der Build-Prozess ist einheitlich. Die Executables sind natürlich plattformabhängig.
Martin v. Löwis schrieb:
Ich empfehle, die Ziele zu überdenken und doch eine Installationsprozedur zu erlauben. Ist echt viel einfacher.
Okay. Wenn Du das schon sagst, dann werde ich das nochmal bedenken. -- Schönen Gruß - Regards Hartmut Goebel Goebel Consult Spezialist für IT-Sicherheit in komplexen Umgebungen http://www.goebel-consult.de
--On 19. Juni 2008 12:15:57 +0200 Hartmut Goebel <h.goebel@goebel-consult.de> wrote:
Hi,
ich möchte eine kleine Anwendung schreiben, die ohne Installation auf Win32, Linux und OS-X läuft.
Kannst Du nicht einfach die Applikation webfähig machen und einen normalen Browser als Frontend vorsehen? Das sollte mit den existierenden Frameworks trivial sein und Du sparst Dir die gesamte Komplexität mit diversen UI Toolkits (unnötiger Overhead, unnötige Komplexität, fehleranfällig - für den Entwickler und für den Anwender). Andreas
Andreas Jung schrieb:
Kannst Du nicht einfach die Applikation webfähig machen und einen normalen Browser als Frontend vorsehen? Das sollte mit den existierenden Frameworks
Wenn ich mir die geringe Komplexität der Anwendung anschaue und den Aufwand, den ich Treiben müßte, mich in GUI einzubauen, dann hast Du wohl recht. Warum habe ich da nicht früher dran gedacht? Danke :-) -- Schönen Gruß - Regards Hartmut Goebel Goebel Consult Spezialist für IT-Sicherheit in komplexen Umgebungen http://www.goebel-consult.de
Wie kann ich erreichen, dass die Anzeige der Skripte (die wahrscheinlich auf stdout ausgegeben werden?) innerhalb des Qt-Programms angezeigt werden?
Den Prozess mittels QProcess starten und die Signale "readyReadStandardError" und "readyReadStandardOutput" anfangen. Innerhalb der Slots für diese Signale kannst du per "readAllStandardError" bzw. "readAllStandardOutput" die Ausgabe des Prozesses lesen und in deinem Widget anzeigen.
Danke, das werde ich mir mal ansehen.
Allerdings bin ich der Meinung, dass es eleganter, realitätsnäher und noch dazu lehrreicher ist, die Skripte so umzuschreiben, dass sie ohne Probleme als Module importiert werden können, und diese Module dann aus der GUI heraus anzusprechen. Just my 2 cents
ok, das werde ich für meine python-scripte auch so machen. Aber ich habe auch einige shellscripe, die ich auf diesem Wege starten wollte. Oder gibt es eine Möglichkeit, aus Python heraus eine konsole mit dem entsprechenden Script zu starten? -- Uwe Wilske
participants (9)
-
"Martin v. Löwis" -
Andreas Jung -
Diez B. Roggisch -
Dinu Gherman -
Harald Armin Massa -
Hartmut Goebel -
Marek Kubica -
Sebastian Wiesner -
Uwe Wilske