hallo,
seien wir doch ehrlich python kann viel, ausser aus einen script eine venueftige .exe zu machen.
egal ob mit py2exe pyInstaller oder cx_freeze (mein favorit) irgendwelche probleme tauchen immer auf. und zwar solche art von problemen die man nur schwer lokalisieren und beheben kann. und den ganzen python interpreter will man wegen der groesse nicht unbedingt mitschleppen...
oder?
standalone apps fuer windows mit python nicht moeglich
-
querdenker
- User
- Beiträge: 424
- Registriert: Montag 28. Juli 2003, 16:19
- Wohnort: /dev/reality
Ja und? Das vermeintliche Problem sind die "Packer", mit denen man die "Standalone"-Anwendung erstellt. Nicht die Programmiersprache als solches.
I'm not getting paid for being Mr. Nice Guy!
Hinzu kommt: eine .py-Datei kann ich auf meinem Computer auch ausführen, eine EXE würde nur zu einer Fehlermeldung führen. Das ist also eher ein Windows-Problem als das man dies der Programmiersprache anlasten kann, die ja betriebssystemübergreifend sein will. Warum gibt es unter Windows-Nutzern überhaupt den immer wiederkehrenden Wunsch, alles zu einer EXE zu verpacken? Kann man dem typischen Windows-Nutzer nicht zumuten, zunächst selbst die passende Laufzeitumgebung (sei es Python, sei es Java oder auch .NET) erst einmal zu installieren? Ist das eine zu große Hürde für das eigene Programm? Dann bitte bei Microsoft beschweren. OS X oder Ubuntu schaffen es ja auch, Python standardmäßig (wenn auch nicht immer in der aktuellsten Version) mitzuliefern.
Stefan
Stefan
Nein, kann man nicht.Kann man dem typischen Windows-Nutzer nicht zumuten, zunächst selbst die passende Laufzeitumgebung (sei es Python, sei es Java oder auch .NET) erst einmal zu installieren?
99% der Computernutzer wissen nicht was eine Laufzeitumgebung überhaupt ist. Der normale Computernutzer ist schon froh über sein Wissen, dass man exe-Dateien ausführen kann und es war schwierig für ihn überhaupt zu diesem Punkt zu kommen. Alles was über dieses mühsam erlernte Wissen hinaus geht ist einfach zu viel. Desweiteren interessiert es den normalen Computernutzer einen Scheißdreck in welcher Programmiersprache das Programm verfasst wurde, welches er benutzen will. Dementsprechend wenig Verständnis darf man erwarten sich mit solchen Themen auseinanderzusetzen. Plattformunabhängigkeit ist für die meisten Computernutzer irrelevant. Der normale Computernutzer hat einen PC oder Laptop und der läuft schon seit 15 Jahren mit Windows (welche Version auch immer). Linux hat hier einen Anteil von unter 1% (siehe hier oder hier).
Sich über Microsoft beschweren hilft da auch herzlich wenig. Was würde es Microsoft denn bringen? Außer einem riesigen Mehraufwand an Support? Bedenke bitte das Windows auf nahezu 100% aller Firmen-PCs mit entsprechenden Wartungsverträgen läuft.
Fazit: Wenn man auf der wichtigsten Plattform für Desktop-PCs vertreten sein will, muss man sich entsprechend anpassen. Dazu gehört das eine Anwendung als exe geliefert wird (Ich spreche natürlich vom Endanwender. Software für Experten oder Frameworks sind natürlich was anderes).
MFG HerrHagen
Hier mal wieder der obligatorische Hinweis auf ein portable Python, mit dem diese Nebeneffekte nicht auftreten.
http://ms4py.org/2010/05/05/python-portable-windows/
Eine große Anwendung mit vielen Abhängigkeiten wie GTK und matplotlib kommt gepackt auf 40 MB und entpackt auf ca. 100 MB, ich sehe das aufgrund der heutigen Festplattenkapazitäten ebenfalls als lächerlich klein an.
http://ms4py.org/2010/05/05/python-portable-windows/
Genau das machen die ganzen Tools doch auch... Der Interpreter hat geschätzt eine Größe von 4MB, ich sehe darin überhaupt kein Problem.Costi hat geschrieben:und den ganzen python interpreter will man wegen der groesse nicht unbedingt mitschleppen...
Eine große Anwendung mit vielen Abhängigkeiten wie GTK und matplotlib kommt gepackt auf 40 MB und entpackt auf ca. 100 MB, ich sehe das aufgrund der heutigen Festplattenkapazitäten ebenfalls als lächerlich klein an.
„Lieber von den Richtigen kritisiert als von den Falschen gelobt werden.“
Gerhard Kocher
http://ms4py.org/
Gerhard Kocher
http://ms4py.org/
HerrHagen, du hast Recht, dass es den Anwender nicht interessieren muss, in welcher Programmiersprache ein Programm geschrieben ist. Aber es muss ihn auch nicht interessieren, ob es nun eine Datei ist, die auf EXE endet oder nicht. Er wird sich in der Regel nicht diese eine Datei installieren, sondern eines dieser üblichen Setup-Programme ausführen, die sich um alles mögliche kümmern. Und da kann problemlos die passende Laufzeitumgebung mit dabei sein.
Diese Diskussion (oh, das JRE ist zu groß, oh, AIR ist zu groß, oh, .NET ist zu groß) führe ich immer mal wieder seit inzwischen über 15 Jahre und es war noch nie ein dauerhaftes Problem. Das "oh gott, das ist zu groß"-Argument zählt daher IMHO nicht. Wenn ein paar MB mehr und damit ein bisschen mehr Warten beim Download (auf CD oder DVD wäre das ja eh kein Thema) entscheidend für den Nutzer sind, die Software nicht haben zu wollen, dann ist sie vielleicht nicht gut genug.
Nach wie vor denke ich, ist es kein Problem der Programmiersprache, wenn sie nicht Windows direkt unterstützt. Das kann man als jemand, der diese Sprache gerne für Windows-Progrämmchen benutzen will, doof finden und vielleicht ist es für die Verbreitung der Sprache nicht zuträglich, aber herrje, 2x ein Setup.exe auszuführen (Python und Programm) statt nur einmal kann ich jetzt nicht sonderlich kompliziert finden - sollte denn das Packen der Laufzeitumgebung in das Setup des eigenen Programms wirklich nicht funktionieren.
Stefan
Diese Diskussion (oh, das JRE ist zu groß, oh, AIR ist zu groß, oh, .NET ist zu groß) führe ich immer mal wieder seit inzwischen über 15 Jahre und es war noch nie ein dauerhaftes Problem. Das "oh gott, das ist zu groß"-Argument zählt daher IMHO nicht. Wenn ein paar MB mehr und damit ein bisschen mehr Warten beim Download (auf CD oder DVD wäre das ja eh kein Thema) entscheidend für den Nutzer sind, die Software nicht haben zu wollen, dann ist sie vielleicht nicht gut genug.
Nach wie vor denke ich, ist es kein Problem der Programmiersprache, wenn sie nicht Windows direkt unterstützt. Das kann man als jemand, der diese Sprache gerne für Windows-Progrämmchen benutzen will, doof finden und vielleicht ist es für die Verbreitung der Sprache nicht zuträglich, aber herrje, 2x ein Setup.exe auszuführen (Python und Programm) statt nur einmal kann ich jetzt nicht sonderlich kompliziert finden - sollte denn das Packen der Laufzeitumgebung in das Setup des eigenen Programms wirklich nicht funktionieren.
Stefan
wenn ich mich richtig erinnere ist die python installation 40 megabyte gross (es sei denn man will sich die muehe machen eine eigene private python distribution zu unterhalten wo nur das drinn ist was das programm braucht - erst dann kommt man auf die 4 megabyte.), dass ist auch bei heutigen computerleistungen zuviel und fuer ein endbenutzer ein enteschidenes argument was anderes zu benutzen
die schuld auf dem Packer zu schieben finde ich nicht richtig, die Packer gehoeren zur sprache selber, "batteries included".
wie ist das eigentlich wenn man den benutzer sagt das er python wie java brauch. es gibt ja mehrer versionen von python und die letzte installierte version fuehrt automatisch die .py dateien aus....
und bei java gibt es ja eine .jar die ausgefuehrt werden muss, bei python hat man sowas nicht, der benutzer muss eine bestimmte datei die in einen ordner ist doppecklicken, das ist voellig unzumutbar.
dieses problem mit der einfachen exe wird meiner meinung nach einfach zu oft verleugnet, in anderen sprachen ist das viel einfacher (auch in manche interpretierbare sprachen)
edit:
ich glaube auch das python im gegensatz zu java was im start menu schreibt, das ist das letzte ein endbenutzer haben will.
die schuld auf dem Packer zu schieben finde ich nicht richtig, die Packer gehoeren zur sprache selber, "batteries included".
wie ist das eigentlich wenn man den benutzer sagt das er python wie java brauch. es gibt ja mehrer versionen von python und die letzte installierte version fuehrt automatisch die .py dateien aus....
und bei java gibt es ja eine .jar die ausgefuehrt werden muss, bei python hat man sowas nicht, der benutzer muss eine bestimmte datei die in einen ordner ist doppecklicken, das ist voellig unzumutbar.
dieses problem mit der einfachen exe wird meiner meinung nach einfach zu oft verleugnet, in anderen sprachen ist das viel einfacher (auch in manche interpretierbare sprachen)
edit:
ich glaube auch das python im gegensatz zu java was im start menu schreibt, das ist das letzte ein endbenutzer haben will.
cp != mv
Da hast du recht. Wenn nach dem Setup alles passt dann ist die Welt in Ordnung.sma hat geschrieben:Aber es muss ihn auch nicht interessieren, ob es nun eine Datei ist, die auf EXE endet oder nicht. Er wird sich in der Regel nicht diese eine Datei installieren, sondern eines dieser üblichen Setup-Programme ausführen, die sich um alles mögliche kümmern.
Hier liegt das eigentliche Problem. Nehmen wir mal an, man macht ein Setup, bei dem einfach vorher die normale Python-Installation abläuft, damit das eigene Programm direkt als .py lauffähig ist. Die Standard-Python-Installation ist dafür schon mal nicht zu gebrauchen. Die installiert default-mäßig schon mal einen ganzen Zoo an Verknüpfungen auf Desktop und Startmenü mit und istallier sich unter c:/pythonXX. Der Nutzer wird sich dann früher oder später fragen: was ist dieses Python, das seit neuesten in meinem Start-Menü auftaucht? Irgendwelche fiese Spyware? Und schon ist es deinstalliert und das Programm läuft nicht mehr. Der Pfad unter dem installiert wird widerspricht auch jeder Konvention. Kurzum: die Standard-Installation ist gut, wenn man selber zum Programmierer werden will. Als Laufzeitumgebung taugt sie jedoch nicht im geringsten.sma hat geschrieben:Das kann man als jemand, der diese Sprache gerne für Windows-Progrämmchen benutzen will, doof finden und vielleicht ist es für die Verbreitung der Sprache nicht zuträglich, aber herrje, 2x ein Setup.exe auszuführen (Python und Programm) statt nur einmal kann ich jetzt nicht sonderlich kompliziert finden - sollte denn das Packen der Laufzeitumgebung in das Setup des eigenen Programms wirklich nicht funktionieren.
Außerdem benötigt ein Python-Programm selten nur die Python-Standard-Bibliothek (wenn dem so wäre gibt es auch mit py2exe und Konsorten kaum Probleme). Das heißt es bleibt nicht bei einer Installation, sondern es können auch mal 4-5 sein. Das geht dann natürlich weit über das zumutbare hinaus. Natürlich könnte man auch alles in ein Setup packen, aber dafür müsste man natürlich wissen, was wohin installiert und registriert wird. Das herauszubekommen ist sicher eine lösbare Aufgabe, aber für die grundlegende und vermeintlich einfache Aufgabe ein Programm auch auf einem anderen PC als dem eigenen laufen zu lassen ziemlich kompliziert. Wenn eine Python-Installation als globale Laufzeitumgebung genutzt werden soll (d.h. mehrere Python-Programme greifen auf eine Python-Installation zurück), stellt sich zudem die Frage in welcher Version Python vorliegt. Man kann natürlich mehrere Versionen installieren, es gibt allerdings nur eine Verknüpfung py mit einem Programm. Man braucht also zwangsläufig eine zwischen liegende Logik, die die passende Version raussucht.
Zusammenfassend kann man sagen, dass es keinen wirklich tollen Weg gibt Python-Programme unter Windows zu deployen. Es gibt Wege, aber die funktionieren nicht so einfach wie man sich das vorstellt und wie man es gewöhnt ist. Wenn dieses Problem schon früher gelöst worden wäre, würde Python heut nicht im Mittelfeld mitspielen, sondern an der Spitze (wo es hinbgehört).
-
BlackJack
@Costi: Welcher der Packer gehört zur Sprache selber? Und wenn das in die Sprachdefinition aufgenommen würde, beträfe das auch Implementierungen die in ganz anderen "Ökosystemen" laufen wie IronPython oder Jython. Und letztlich auch PyPy.
Bei Java gibt es auch viele Programme, die neben einer oder mehrerer JAR-Dateien eine ``programmname.bat`` und/oder ``programmname.sh`` beinhalten. Das doppelklicken einer solchen Datei ist nicht "voellig unzumutbar". Wer daran scheitert, ist auch mit jedem nicht völlig trivialem Programm überfordert, und da fragt man sich warum derjenige dann einen Rechner verwendet.
Man kann so ein Programm auch mit einem Installer versehen, der einen Startmenüeintrag für die betreffende Datei erstellt.
Aus reinen Python-Programmen kannst Du übrigens auch eine Art ausführbares ``*.jar`` machen. Einfach die Dateien in ein ZIP mit der Endung ``*.egg`` stecken und eine ``__main__.py``, die den Startcode enthält. Das kann man dann (ab 2.6) mit ``python programm.egg`` starten.
Das letzte Java was ich unter Windows installiert habe, hat ebenfalls etwas ins Startmenü geschrieben. Einen Eintrag zum Deinstallieren, irgend so einen Webstart-Kram, und was zum Lesen. Ausserdem gab's einen "cron job" der regelmässig nach Updates geschaut hat und das ggf. mit einem Fenster und einem Icon im System Tray kundgetan hat.
Es mag ja sein, dass das Erstellen von ausführbaren Programmen für Windows-Benutzer komplizierter ist, als es sein müsste, aber es ist entgegen der Behauptung im Betreff nicht unmöglich. Es gibt ja Programme, die als Installer und komplett mit den benötigten Modulen und Bibliotheken ausgeliefert werden. Sowohl im Betreff, als auch in den anscheinend hastig runtergeschriebenen Beiträgen, übertreibst Du ziemlich ("nicht unmoeglich", "voellig unzumutbar", "das letzte was ein endbenutzer haben will").
Bei Java gibt es auch viele Programme, die neben einer oder mehrerer JAR-Dateien eine ``programmname.bat`` und/oder ``programmname.sh`` beinhalten. Das doppelklicken einer solchen Datei ist nicht "voellig unzumutbar". Wer daran scheitert, ist auch mit jedem nicht völlig trivialem Programm überfordert, und da fragt man sich warum derjenige dann einen Rechner verwendet.
Man kann so ein Programm auch mit einem Installer versehen, der einen Startmenüeintrag für die betreffende Datei erstellt.
Aus reinen Python-Programmen kannst Du übrigens auch eine Art ausführbares ``*.jar`` machen. Einfach die Dateien in ein ZIP mit der Endung ``*.egg`` stecken und eine ``__main__.py``, die den Startcode enthält. Das kann man dann (ab 2.6) mit ``python programm.egg`` starten.
Das letzte Java was ich unter Windows installiert habe, hat ebenfalls etwas ins Startmenü geschrieben. Einen Eintrag zum Deinstallieren, irgend so einen Webstart-Kram, und was zum Lesen. Ausserdem gab's einen "cron job" der regelmässig nach Updates geschaut hat und das ggf. mit einem Fenster und einem Icon im System Tray kundgetan hat.
Es mag ja sein, dass das Erstellen von ausführbaren Programmen für Windows-Benutzer komplizierter ist, als es sein müsste, aber es ist entgegen der Behauptung im Betreff nicht unmöglich. Es gibt ja Programme, die als Installer und komplett mit den benötigten Modulen und Bibliotheken ausgeliefert werden. Sowohl im Betreff, als auch in den anscheinend hastig runtergeschriebenen Beiträgen, übertreibst Du ziemlich ("nicht unmoeglich", "voellig unzumutbar", "das letzte was ein endbenutzer haben will").
Das MSI ist 15 MB groß, nicht 40 MB.Costi hat geschrieben:wenn ich mich richtig erinnere ist die python installation 40 megabyte gross
Schön wäre, wenn die Leute, die das MSI bauen, auch die Konfiguration dafür bequem konfigurierbar zur Verfügung stellen würden (vielleicht machen sie's ja) sodass man auch eine Version z.B. ohne Dokumentation oder was da sonst große Bestandteile sind, bauen kann, sie sich dann natürlich auch an einer anderen Stelle im System installieren lassen muss und man dann auch gleich noch sein eigenes Programm beilegen kann. Kann doch nicht so schwer sein, so ein MSI selbst anzupassen und zu bauen. Vor Jahren habe ich mal mit NSIS gemacht, das war (trotz Forth-artiger Stacksprache) beherrschbar.
Stefan
Ja mit der ganzen Doku, Header-Files und etc. kommt man auf ca. 20 MB, was für eine Laufzeitumgebung aber völlig unnötig ist. Eine Minimal-Installation über das Setup kommt auf ca. 4 MB.Costi hat geschrieben:wenn ich mich richtig erinnere ist die python installation 40 megabyte gross (es sei denn man will sich die muehe machen eine eigene private python distribution zu unterhalten wo nur das drinn ist was das programm braucht - erst dann kommt man auf die 4 megabyte.), dass ist auch bei heutigen computerleistungen zuviel und fuer ein endbenutzer ein enteschidenes argument was anderes zu benutzen
die schuld auf dem Packer zu schieben finde ich nicht richtig, die Packer gehoeren zur sprache selber, "batteries included".
Und warum soll das zu viel sein? So ein Blödsinn. Wie groß ist denn Java... Viele Programme setzen auch eine installierte Java-JRE voraus. Mit Python kann man das eigentlich auch erwarten.
Problematisch wird es erst, wenn man eine Menge von Abhängigkeiten hat. Dann hat man nämlich schnell mal 10 Setup-Dateien, die in einer bestimmten Reihenfolge abgearbeitet werden müssen, wobei manche davon nicht automatisierbar sind. Und nebenbei müssen noch Umgebungsvariablen gesetzt werden. Spätestens dann ist man wirklich in einer Situation, die das Deployment einer Applikation für Windows sehr umständlich macht. Auch die Lösung mit der portable Version ist nicht so elegant, aber IMO die einfachste und wenigstens ohne Nebeneffekte.
„Lieber von den Richtigen kritisiert als von den Falschen gelobt werden.“
Gerhard Kocher
http://ms4py.org/
Gerhard Kocher
http://ms4py.org/
-
querdenker
- User
- Beiträge: 424
- Registriert: Montag 28. Juli 2003, 16:19
- Wohnort: /dev/reality
@costi: wie kommst du auf 40 MB? Die "reine" Python-Installation hat (Stand 2.6.6) 16 MB. Andere Runtime-Installationen (jre, .net) mögen zwar kleiner im Download sein, ziehen dann aber ganz gerne noch weitere Sachen aus dem Netz nach. Entpackt - 'ne "leere" Installation mag 40 MB haben, aber schau dir bitte mal java oder .net an wie es da aussieht. Und wenn man die "leere" python-Installion mal durchsieht - da sind viele Sachen drin die der Endanwender nicht benötigt. Und diesen Überfluss lässt man halt durch py2exe oder cx_freeze oder sonstwas weg.
Das Argument mit den Jar-Files die der User nur noch anklicken muss - kann funktionieren - muss aber nicht. Schon des öfteren erlebt das die Runtime doch etwas zu alt war und der Programmierer das nicht sauber abgeprüft hat. Oder das Jar muss weitere Jars übers Netz nachladen und scheitert dann am Virenscanner/Proxy/name-it-you-got-it. Die Meldungen sind ebensowenig Endverbrauchertauglich, wenn sie den erscheinen. Aber vielleicht hat ja der SysAdmin alles so konfiguriert das Frau Müller sich um nichts mehr kümmern muss. Dann ruft sie einfach an und sagt "Es geht nicht".
Das bauen von Setups, respektive der Präsentation eines Programmes für den User (anlegen einer Verknüpfung auf dem Desktop, Eintrag im Startmenü) - sorry, das ist reine Entwicklungsarbeit. Nicht das Programm oder die Runtime-Umgebung ist schuld.
.Net Anwendung ausgelegt auf .Net 3.5, auf dem Rechner ist nur die Runtime für 2.0, es wird beim Anwendungsstart nicht geprüft - und nu? Nachinstallieren? Durch Frau Müller? Das Spiel geht auch andersrum: In .Net 3.5 ist eigentlich alles von .Net 2.0 drin, also ist nur .Net 3.5 installiert . Allerdings gibt es Anwendungen, die explizit nach .Net 2.0 suchen (über Pfade - ist schlecht programmiert) und nicht finden - Fehlermeldung. Frau Müller ist schon wieder ratlos und ruft nach dem Admin.
IMHO muss ein Benuzter (auch Frau Müller) wissen, was sie mit dem Rechner alles machen kann und wie man Software installiert - Stichworte mündiger User, Führerschein für den Computer / für das Internet.
Alles Easy, anschalten, arbeiten und alles funkioniert - inclusive nie wieder Probleme mit irgendwas haben? Reine Marketinglüge. Keine Entwicklung kann alle Szenarien abfangen, in denen eine Software eingesetzt wird. Keine Entwicklung hat die Zeit tagelang bei jedem einzelnen Benutzer auf dem Schoß zu sitzen und sich jeden einzelnen Handgriff genau erklären zu lassen und zu dokumentieren. Ausgenommen davon sind restriktive oder proprietäre Umgebungen, in denen der Benutzer (fast) nichts darf.
Das Argument mit den Jar-Files die der User nur noch anklicken muss - kann funktionieren - muss aber nicht. Schon des öfteren erlebt das die Runtime doch etwas zu alt war und der Programmierer das nicht sauber abgeprüft hat. Oder das Jar muss weitere Jars übers Netz nachladen und scheitert dann am Virenscanner/Proxy/name-it-you-got-it. Die Meldungen sind ebensowenig Endverbrauchertauglich, wenn sie den erscheinen. Aber vielleicht hat ja der SysAdmin alles so konfiguriert das Frau Müller sich um nichts mehr kümmern muss. Dann ruft sie einfach an und sagt "Es geht nicht".
Das bauen von Setups, respektive der Präsentation eines Programmes für den User (anlegen einer Verknüpfung auf dem Desktop, Eintrag im Startmenü) - sorry, das ist reine Entwicklungsarbeit. Nicht das Programm oder die Runtime-Umgebung ist schuld.
.Net Anwendung ausgelegt auf .Net 3.5, auf dem Rechner ist nur die Runtime für 2.0, es wird beim Anwendungsstart nicht geprüft - und nu? Nachinstallieren? Durch Frau Müller? Das Spiel geht auch andersrum: In .Net 3.5 ist eigentlich alles von .Net 2.0 drin, also ist nur .Net 3.5 installiert . Allerdings gibt es Anwendungen, die explizit nach .Net 2.0 suchen (über Pfade - ist schlecht programmiert) und nicht finden - Fehlermeldung. Frau Müller ist schon wieder ratlos und ruft nach dem Admin.
IMHO muss ein Benuzter (auch Frau Müller) wissen, was sie mit dem Rechner alles machen kann und wie man Software installiert - Stichworte mündiger User, Führerschein für den Computer / für das Internet.
Alles Easy, anschalten, arbeiten und alles funkioniert - inclusive nie wieder Probleme mit irgendwas haben? Reine Marketinglüge. Keine Entwicklung kann alle Szenarien abfangen, in denen eine Software eingesetzt wird. Keine Entwicklung hat die Zeit tagelang bei jedem einzelnen Benutzer auf dem Schoß zu sitzen und sich jeden einzelnen Handgriff genau erklären zu lassen und zu dokumentieren. Ausgenommen davon sind restriktive oder proprietäre Umgebungen, in denen der Benutzer (fast) nichts darf.
I'm not getting paid for being Mr. Nice Guy!
also bei mir ist "c:/Python27" 43.1 Megabyte gross. was ich meinte ist das niemand lust hat da rummzufummeln was er brauch und was er nicht brauch wenn er das ganze mit seiner app mit deployen will.
bei der sache mit dem "den muendigen user" haben wir dan unterschiedliche philosophien, ich glaube, dass der benutzer IPhone maessig intuitiv rummclicken sollen koennte ohne nachzudenken und dabei immer ein leises "ist ja geil" von sich geben.
das ganze frickel zeugs sollte bei dem programmieren bleiben.
@blackjack:
das mit dem __run__.py im .egg wusste ich garnicht.
kann ich wenn python installiert ist .eggs einfach doppelclicken um sie zu starten?
und was ist wenn ich python 2 code habe und python 3 installiert ist...?
mann kann python uebrigens auch automatisiert installieren: http://www.python.org/download/releases/2.4/msi
bei der sache mit dem "den muendigen user" haben wir dan unterschiedliche philosophien, ich glaube, dass der benutzer IPhone maessig intuitiv rummclicken sollen koennte ohne nachzudenken und dabei immer ein leises "ist ja geil" von sich geben.
das ganze frickel zeugs sollte bei dem programmieren bleiben.
@blackjack:
das mit dem __run__.py im .egg wusste ich garnicht.
kann ich wenn python installiert ist .eggs einfach doppelclicken um sie zu starten?
und was ist wenn ich python 2 code habe und python 3 installiert ist...?
mann kann python uebrigens auch automatisiert installieren: http://www.python.org/download/releases/2.4/msi
cp != mv
Costi hat geschrieben:also bei mir ist "c:/Python27" 43.1 Megabyte gross.
Dann hast du eben ein paar zusätzliche Libs installiert...
Jeder Programmierer sollte doch die Dependencies seiner App kennen und deshalb auch genau wissen, was er jetzt braucht und was nicht...Costi hat geschrieben:was ich meinte ist das niemand lust hat da rummzufummeln was er brauch und was er nicht brauch wenn er das ganze mit seiner app mit deployen will
„Lieber von den Richtigen kritisiert als von den Falschen gelobt werden.“
Gerhard Kocher
http://ms4py.org/
Gerhard Kocher
http://ms4py.org/
-
lunar
@Costi: Warum erzählst Du uns das alles? Durch Jammern hat sich noch nie etwas geändert.
Damit, dass es ein Problem gibt.Costi hat geschrieben:mit der meinung das man ein problem erstmal erkennen muss um es zu beheben oder das das erstellen von .exen in python vergleichsweise umstaendlich ist?
Das Leben ist wie ein Tennisball.
