EXE mit cx_Freeze erstellen

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
murph
User
Beiträge: 622
Registriert: Freitag 14. April 2006, 19:23
Kontaktdaten:

das ist falsch!
der pythoncode ist doch such glrich!
die python24.dll richtet alles, nur betriebssysteme, die diese dll nicht verstehen, sind davon ausgeschlossen.
http://www.cs.unm.edu/~dlchao/flake/doom/
JR
User
Beiträge: 286
Registriert: Montag 20. Februar 2006, 16:43
Wohnort: Berlin

Also ist es richtig. Ich meinte, dass es nicht möglich ist, eine EIGENSTÄNDIGE helloworld.exe kompilieren, wie es z.B. in C möglich ist. Man benötigt bei Python mind. die python.dll.

Also bis denn
JR
BlackJack

Definiere "wie in C möglich". Auch bei C brauchst Du im Normalfall die Laufzeitbibliothek die zum Compiler passt.

Und bei py2exe & Co wird der Python-Interpretierer mitgeliefert, verhält sich also so ähnlich wie eine statisch gebundene Laufzeitbibliothek bei C.
murph
User
Beiträge: 622
Registriert: Freitag 14. April 2006, 19:23
Kontaktdaten:

also der code wird eigentlich immer noch immer als pyc weitergereicht, welches universell ist.
[quote = JR], welche auf den Betriebssystemen läuft, die dem Betriebssystem entsprechen, auf welchem kompiliert wurde!? [/quote]#
der anhang hat mir zu schaffen gemacht, ob du da den überblick hast ;-)
http://www.cs.unm.edu/~dlchao/flake/doom/
JR
User
Beiträge: 286
Registriert: Montag 20. Februar 2006, 16:43
Wohnort: Berlin

Hi!

Wenn ich eine *.exe erstelle und betriebssystemspezifische Module einbinde, dann funktioniert das Kompilieren ansich nur auf dem entsprechenden OS und das Auführen der Anwendung ist ebenfalls OS-gebunden. Falsch?

Grüße und elider Gute Nacht, schaue morgen wieder rein.

Grüße
JR
murph
User
Beiträge: 622
Registriert: Freitag 14. April 2006, 19:23
Kontaktdaten:

also ich bin mmir nicht 100% sicher, aber wine bedeutet doch
Wine
Is
Not a
Emulator
sprich: es stellt nur bestimmte bibliotheken zur verfügung...
außerdem laufen fast alle *.exe sowohl unter win95 als auch winXP^^
http://www.cs.unm.edu/~dlchao/flake/doom/
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

JR hat geschrieben:betriebssystemspezifische Module
Hi JR!

Mit dem Wort "betriebssystemspezifisch" hast du dir die Antwort ja schon selber gegeben. Verwendest du Module, die nur für ein spezifisches Betriebssystem existieren, und du im Programm dafür keinen Ersatz, für andere Betriebssysteme, verwendest, dann kannst du das Programm "nur" unter dem Betriebssystem verwenden, für das es programmiert wurde.

Du kannst nicht Module aus "pywin32" verwenden und glauben, dass diese auch unter Linux funktionieren.

Und jetzt zu einer anderen Frage...

Verteilst du reinen Python-Quellcode, der so geschrieben ist, dass er unter mehreren Betriebssystemen läuft, dann braucht der Benutzer deines Codes einfach nur Python installieren und schon läuft die Sache.

Schlimmer wird es, wenn du mehrere Abhängigkeiten hast, die der Benutzer nachinstallieren müsste. Um dieses Problem (für den Kunden) zu umgehen, setze ich recht gerne cx_Freeze ein. cx_Freeze packt die abhängigen Module mit in die Exe rein oder kopiert benötigte Dateien in den "dist"-Ordner. Der Vorteil von cx_Freeze ist, dass ich damit Pakete für Windows und für Linux machen kann. Natürlich muss man das Paket für Linux auf einer Linux-Maschine erstellen und das Paket für Windows auf einer Windows-Schüssel. Woher soll denn cx_Freeze sonst die für die Platform kompilierten Dateien bekommen.

Und jetzt noch zu einer anderen Frage...

Python ist eine interpretierte Programmiersprache. Da wird nichts in irgendwelchen Maschinencode übersetzt, so dass man eine einzelne lauffähige EXE-Datei erhält. Auch wenn du mit cx_Freeze eine EXE-Datei erstellst, dann wird intern trotzem noch von Python "interpretiert". Aber, was ist so schlimm daran? Visual Basic Programme funktionieren auch nicht ohne die VB-Runtime-Library und müssen ja auch installiert werden.

Warum bist du eigentlich so versteift darauf, eine einzelne EXE-Datei zu machen? Wenn es sich um ein Programm für einen Kunden handelt, dann kann man ja ein Setup dafür erstellen. Python zu installieren ist nicht unbedingt eine Aufgabe, die man niemandem zutrauen kann.

Du kannst ja dein Programm mit cx_Freeze zusammenstellen und dann z.B. mit InnoSetup ein Setup daraus generieren lassen. Das dauert nur ein paar Minuten.

Aber meist rentiert sich dieser (paar Minuten) Aufwand nicht, da man auf dem Zielcomputer einfach nur Python installieren muss und fertig. Das Dot-NET Framework muss man ja auch installieren, damit ein Dot-Net-Programm funktioniert.

lg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
JR
User
Beiträge: 286
Registriert: Montag 20. Februar 2006, 16:43
Wohnort: Berlin

Hallo!

Also ich begründe eben mal, weshalb ich mich so sehr dafür interessiere, was "in etwa" beim Estellen einer *.exe-Datei aus Pythoncode passiert:

Erstens:
Ist eigentlich ganz simpel. Bei mir auf Arbeit entwickeln wir mit einer Datenbankumgebung, welche vom Hersteller in C geschrieben wurde und sauschnell ist. Eine Schleife über 1000 Datensätze einer Tabelle mit mehreren Hundert Spalten und mit einfachen Schreibvorgängen wird da in vielleicht einer Sekunde erledigt. Beispielsweise das Durchnummerieren eines Spaltenwerts etc.

Ich habe noch keine Vergleiche mit Python angestellt. Doch wenn Python ausschließlich interpretieren kann, wird solch eine Pflegeschleife oder auch ein Datenimport aus einer bereitgestellten externen Datei sicherlich wesentlich langsamer von statten gehen.

Zweitens:
Ich glaube mein Chef wäre nicht begeistert, wenn ich ihm meine an unsere Bedürfnisse angepasste Schnittstelle eines Datentransfers zwischen unserem Produkt und MySQL präsentiere und ihm erkläre, dass von nun an all unsere Kunden Python installieren müssen. Er selbst hält zwar sehr viel von Python, dennoch ist es denke ich eher in seinem Sinn, wenn ich eine Anwendung bastle, welche eigenständig auf einem festen OS laufen wird.

Viele Grüße
Jamil
Benutzeravatar
Masaru
User
Beiträge: 425
Registriert: Mittwoch 4. August 2004, 22:17

Ein Hauptgrund Executables auszuliefern, ist ja schließlich auch der kommerzielle. Nicht alles, was mit Python gemacht wird, ist schließlich OpenSource ;).
BlackJack

JR hat geschrieben:Ich glaube mein Chef wäre nicht begeistert, wenn ich ihm meine an unsere Bedürfnisse angepasste Schnittstelle eines Datentransfers zwischen unserem Produkt und MySQL präsentiere und ihm erkläre, dass von nun an all unsere Kunden Python installieren müssen. Er selbst hält zwar sehr viel von Python, dennoch ist es denke ich eher in seinem Sinn, wenn ich eine Anwendung bastle, welche eigenständig auf einem festen OS laufen wird.
Wenn Du die Anbindung in Java, C# oder einer anderen .NET Sprache schreiben würdest, dann müssten sich die Kunden wesentlich "fettere" Interpretierer zusätzlich installieren. Und meiner Erfahrung nach machen Kunden so etwas auch.

Ich würde an Deiner Stelle zwei Möglichkeiten anbietet. Python und Dein Programm in einem Installer und beides getrennt. Dann können es die Kunden entweder einfach und gross haben, oder sie haben die Möglichkeit schön kleine Updates zu bekommen, weil dann ja nur noch die Python-Skripte erneuert werden müssen.

So richtig erklärt das auch immer noch nicht Deine "eine ausführbare EXE Fixierung". Kunden sind es durchaus gewohnt einen Installer zu bekommen und ihnen ist in der Regel wurscht ob da eine oder 20 Dateien installiert werden.
BlackJack

Masaru hat geschrieben:Ein Hauptgrund Executables auszuliefern, ist ja schließlich auch der kommerzielle. Nicht alles, was mit Python gemacht wird, ist schließlich OpenSource ;).
Du wirfst da zwei orthogonale Konzepte durcheinander. Quelloffene Software lässt sich problemlos verkaufen. Du kannst per Lizenz verbieten, dass der Code weitergegeben werden darf. Ob sich der Kunde daran hält, ist völlig unabhängig davon ob er die Quellen oder nur "unlesbare" Binärdateien hat.
Benutzeravatar
Masaru
User
Beiträge: 425
Registriert: Mittwoch 4. August 2004, 22:17

@BlackJack: Das weisst du, dass weiss ich ... weiss bzw. schätzt das aber auch der Kunde so?

Marketing und Sales haben da ganz eigene Vorstellungen und Anforderungen, und ich wette mit dir, dass die meisten eine "EXE (etc. pp) und unlesbare Binärdaten" haben wollen ... wetten ;)?
BlackJack

Da würde ich sogar wetten. Den meisten ist es IMHO egal solange es einfach zu installieren ist.
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

BlackJack hat geschrieben:Den meisten ist es IMHO egal solange es einfach zu installieren ist.
Hi!

Ein Setup! Auch wenn das Setup nur eine einzige Datei in einen Ordner kopiert und einen Startmenü-Eintrag erstellt. Ein Setup ist Pflicht, sobald sich der Kunde das Programm selber installieren muss! Am Besten noch auf einer CD mit "autostart.ini", damit das Setup-Programm sofort nach dem Einlegen der CD startet.

Das ist es was sich die Kunden erwarten. Ich weiß gar nicht, ob sich das auch die Marketing-Leute wünschen. :K

Das ist auch der Grund, weshalb ich eine Python-Abhängigkeit nicht tragisch sehe. Bei großen Projekten lass ich vom Setup Python und sonstige Abhängikeiten (z.B. wxPython, pyMsSQL, pywin32, usw.) installieren und bei kleinen Projekten verwende ich cx_Freeze.

lg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Benutzeravatar
Masaru
User
Beiträge: 425
Registriert: Mittwoch 4. August 2004, 22:17

... Den meisten ist es IMHO egal solange es einfach zu installieren ist. ...


Und du findest es einfacher Komponenten-Installationen oder gar Updateszenarien zu entwickeln, als einfach nur eine ge-bundelte Binary-Version (egal ob SingleExecutable oder SingleDir) in ein gewünschtes Verzeichnis zu werfen BlackJack?

... die Plausiblitätsprüfungen auf bestehende Python und Nicht-Standard-Bibliotheken/Extensions ist dann natürlich Pflicht. Ebenso wie eine Alternative und dem Benutzer Interaktions- und/oder Entscheidungsmöglichkeiten zu schaffen:

Code: Alles auswählen

Der Installer hat Python 1.5 auf Ihrem System lokalisiert. 

Sie benötigen Python  2.4 um diese Anwendung jedoch ausführen zu können. 

Möchte sie auf Python 2.4 upgraden? 
(Bei Zusage nehmen sie auf eigenen Kappe, dass eventuelle Python 1.5 nutzende Programme Ihre Funktionstüchtigkeit verlieren 
... sagen sie also nicht, wir hätten sie nicht gewarnt).

[OK] [Cancel] [Don't know]
Was ist wenn gerade der Kunde ein Python 2.2 mit entsprechenden SQLite-, wxPython-, Win32 Python Extensions und anderen Versionsabhängigen Modulen auf seinem System hat, und gerade nicht auf 2.4 uppen möchte (darf, kann ... das Repertoire ist nicht gerade klein *g*) ... hmmm ... naja, auch egal :D ... jeder macht's auf seine Weise.

Mir könnten das zuviele Abhängigkeiten sein. Eine Komponente pflicht-uppen: gut; aber dann noch eventuell mehrere: da arbeite ich lieber mit Py2Exe, cx_freeze und PyInstaller Resultaten.

Klar gibt es in unser Branche etwas wie:System Requirements ... aber irgendwo hört dann beim hart gesottensten Benutzer auch die Lust nach Validierungsdialogen auf ;).

Gruß,
>>Masa<<
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

Masaru hat geschrieben:Klar gibt es in unser Branche etwas wie:System Requirements ... aber irgendwo hört dann beim hart gesottensten Benutzer auch die Lust nach Validierungsdialogen auf ;).
Hi Masaru!

Meine Aussage über das obligatorische Setup, widerspricht in keiner Weise dem OpenSource-Gedanken. Es gibt Leute, die möchten sich das Programm lieber nicht vorgefertigt als cx_Freeze-Paket installieren, sondern den Quellcode einsehen können, um z.B. herauszufinden, wie das Programm arbeitet und/oder einfach nur mal kurz eine kleine Änderung vorzunehmen.

Ein Setup ist für den Standard-Anwender. Wie wäre es, wenn man mehrere Möglichkeiten Anbietet? Quellcode in einem TAR-Archiv, Python-Installation (python setup.py install) und eine Setup-Version für Windows. Wenn man sich damit auskennt, dann könnte man auch noch ein RPM- und ein DEB-Installationspaket machen.

Das ist alles eine Frage, wie intensiv ich ein Programm verbreiten möchte. Die ganze Arbeit kann ich mir sparen, wenn ich mich selbst um die Installation beim Kunden kümmern kann oder wenn ich mit erfahrenen Computer-Anwendern rechnen kann. Je mehr Leute ich erreichen möchte, desto komfortabler muss die Installation werden. Das war schon immer so.

Was die Validierungsdialoge beim Installieren betrifft: Man kann Python mehrfach auf einem Computer installieren. Man muss z.B. unter Windows einfach nur einen Parameter beim Aufruf der MSI-Datei angeben, damit die neue Python-Version NICHT zur Standardversion wird. Damit laufen alte Python-Programme wie gewohnt weiter. Beim Installieren könnte man dann z.B. eine Umgebungsvariable (%PYTHONPATH24%) setzen, die den Pfad zur gewünschten Python-Release enthält.
Allerdings würde das die Entwicklung und die Installation stark verkomplizieren.

Alles hat seine Vor- und Nachteile. Ich glaube, es kommt immer darauf an, für wen man programmiert. Den meisten Abhängigkeits-Problemen kann man aus dem Weg gehen, indem man cx_Freeze verwendet und alles, was das Programm benötigt in den Programmordner mit rein packt. Den Quellcode kann man als extra Paket mitliefern.

lg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
BlackJack

Masaru hat geschrieben:
... Den meisten ist es IMHO egal solange es einfach zu installieren ist. ...


Und du findest es einfacher Komponenten-Installationen oder gar Updateszenarien zu entwickeln, als einfach nur eine ge-bundelte Binary-Version (egal ob SingleExecutable oder SingleDir) in ein gewünschtes Verzeichnis zu werfen BlackJack?
Wo habe ich das denn gesagt? Ich sagte es kommt dem gemeinen Anwender nicht darauf an, ob es Binärcode oder Quelltext ist, sondern das es für ihn einfach zu installieren ist. Und da brauchst Du unter Windows einen Installer. Damit das Programm selbst irgendwo hin zu kopieren, sind viele schon "überfordert", die wollen einen Installer und das danach ein Icon in ihrem Startmenü erscheint.

Das man Python und das eigentliche Programm einzeln Installieren kann, ist als Alternative gedacht für Leute, die wissen was sie tun. Als oberstes auf der Downloadseite muss immer ein Komplettinstaller stehen, mit dem Hinweis das man den nehmen soll, wenn man sich nicht sicher ist was man braucht.
JR
User
Beiträge: 286
Registriert: Montag 20. Februar 2006, 16:43
Wohnort: Berlin

Hallo Freezer und alle anderen Interessierten!

Toll, dass das Forum wieder lebt :-)

Weiß jemand, wie ich der *.exe-Datei, welche ich durch FreezePython erstellen ließ, ein Icon zuweisen kann? Mit gängigen Tools geht es nicht, da die Datei kein zu ersetzendes Icon enthält. Selbst Resource Hacker scheitert an der *.exe-Datei.

Wäre schade, wenn ich der *.exe kein Icon zuweisen kann, da ich eine Installationsroutine mit NSIS HM NIS Edit erstellt habe und sämtliche Shortcuts (Startmenü, Quicklaunch, Desktop etc.) dieses weniger schöne Standardsymbol von *.exe-Dateien erhalten :-(

Viele Grüße
JR
Y0Gi
User
Beiträge: 1454
Registriert: Freitag 22. September 2006, 23:05
Wohnort: ja

Der PyInstaller erzeugt wohl nur eine einzige Datei, nämlich die .exe.
JR
User
Beiträge: 286
Registriert: Montag 20. Februar 2006, 16:43
Wohnort: Berlin

HI Yogi!

Danke für den Hinweis, werd ich mir ansehen.

Grüße
JR
Antworten