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:

Beitragvon murph » Freitag 25. August 2006, 21:56

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

Beitragvon JR » Freitag 25. August 2006, 22:17

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

Beitragvon BlackJack » Freitag 25. August 2006, 22:22

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:

Beitragvon murph » Freitag 25. August 2006, 22:24

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 ;-)
JR
User
Beiträge: 286
Registriert: Montag 20. Februar 2006, 16:43
Wohnort: Berlin

Beitragvon JR » Freitag 25. August 2006, 22:26

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:

Beitragvon murph » Freitag 25. August 2006, 22:51

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^^
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5554
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Telfs (Tirol)
Kontaktdaten:

Beitragvon gerold » Freitag 25. August 2006, 22:56

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

Beitragvon JR » Samstag 26. August 2006, 09:20

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

Beitragvon Masaru » Samstag 26. August 2006, 09:53

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

Beitragvon BlackJack » Samstag 26. August 2006, 10:04

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

Beitragvon BlackJack » Samstag 26. August 2006, 10:07

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

Beitragvon Masaru » Samstag 26. August 2006, 17:53

@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

Beitragvon BlackJack » Samstag 26. August 2006, 20:50

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: 5554
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Telfs (Tirol)
Kontaktdaten:

Beitragvon gerold » Samstag 26. August 2006, 21:00

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

Beitragvon Masaru » Sonntag 27. August 2006, 01:18

... 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<<

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder