Hi... Ich hab im Forum nachgefragt, wie man denn am Besten ein End-User Programm anbieten sollte, siehe: http://www.python-forum.de/viewtopic.php?f=1&t=35061 Das wird ja spätestens dann kompliziert, wenn man externe Module nimmt. Aber auch wenn es nur eine simple .py Datei ist: Wie einem Otto-Normalo-Windows-Benutzter beibringen, wie man das nun nutzten kann?!? Eigentlich gibt es da nicht wirklich was. Der Königsweg: 1. Paket in alle Linux Distributionen bringen 2. Für Windows, Mac: Tools wie PyInstaller, cx-freeze nutzten Schön und gut. Funktioniert aber nur, wenn man reichlich man-power hat. Denn das ist alles viel Arbeit. Zumindest wesentlich mehr als sein Programm nur im PyPi zu registrieren und hoch zu laden... Ich hätte da eine Idee: "PyPi-GUI" Ist eine Art Synaptic für Python Pakete: * Zielgruppe sind Endanwender, die gern ein Programm nutzten wollen * PyPi-GUI selbst per PyInstaller, cx-freeze anbieten * Bei der Installation wird ein Python Interpreter installiert, wenn nicht vorhanden * Mit PyPi-GUI kann man dann den PyPi durchsuchen * z.B. gefiltert nach: Intended Audience :: End Users/Desktop * Programm auswählen und installieren: * Es wird ein virtualenv erzeugt * Paket per pip installiert * Update erfolgt via pip --upgrade Wenn es sowas gäbe, bräuchten Entwickler von End-User-Programmen nur sein Paket im PyPi hoch zu laden (Was ja ohne großen Aufwand geht). Dann eine kurze Anleitung aufzeigen: A. PyPi-GUI installieren B. Programm auswählen und installieren Der Entwickler kann somit auf egal welcher Plattform arbeiten und jeder End-Anwender kann auf allen Plattformen das Programm auf einfacher Weise installieren und nutzten. Da virtualenv genutzt wird, wird A die globale Python Installation sauber gehalten und B kann man das ganze auch einfach wieder Löschen... Das ganze habe ich auf bei https://github.com/pypa/packaging-problems/issues/57 in die Runde geworfen. Das Problem ist allerdings: Ich habe werde von PyInstaller, cx-freeze Erfahrungen und habe GUIs eigentlich immer nur mit TkInter gebaut. Wobei das letztere ja auch vollkommen reichen kann. Evtl. ist TkInter auch eine gute Idee, weil es ja quasi bei CPython mit installiert wird (unter Windows)... Auf langer Sicht gesenen, wäre es natürlich super, wenn es das schon direkt in Python dabei ist. Aber das ist ja ein weiter, weiter Weg... Irgendwelche Anmerkungen/Ideen hier??? Mfg. Jens
Hallo Jens, ich habe ein paar Anmerkungen dazu, warum ich das fuer einen schwierigen Plan halte. Das faengt schon mal damit an, dass ich deine Annahme, man muesse als Entwickler ja nur eine Version bereitstellen, in Frage stelle. Schon simple Pfadoperationen koennen schief gehen, wenn man nicht wenigstens mal testes auf einer nicht-windows bzw. unixoiden Plattform. Auch einfache GUI-Anwendungen mit Tkinter sehen unterschiedlich aus. Das mag man tolerieren, wenn man aber ein bisschen Qualitaetskontrolle ausueben will, zwingt einen auch das dazu, sich auf den verschiedenen Plattformen ein Bild zu machen. Nehmen wir an, das wurde gemacht, das Paket kann fuer alle Zielplattformen verwandt werden. Dann ist das, was du dort vor hast, in meinen Augen immer noch nicht schluessig. Denn es geht an den jeweiligen Nutzungsgewohnheiten der User vorbei. Die laden sich einen Installer runter, und fertig. Das willst du jetzt aendern, sie sollen eine Art "App-Store” verwenden, der aber noch extra zu installieren ist - durchaus schon eine Huerde. Aber dann geht es erst richtig los. Denn die App meiner Usertraeume braucht Qt5, Numpy und wasweisich. Alles Dinge, die sich *nicht* ueber pip instalieren lassen (unter Windows zumindest mal), noch dicke Library-Abhaengigkeiten haben, die man extra installieren muss usw. Da musst du dann passen, und am Ende landet man bei einem Bruchteil an Programmen, fuer die das alles wirklich funktioniert. Darum finde ich die Ansaetze von cx_freeze & Co schon durchaus gelungen: auf einer Entwicklermaschine finden sich all die Abhaengigkeiten, die man braucht. Alles, was dann “nur” noch bleibt ist das zusammensammeln. Was halt wirklich helfen wuerde in meinen Augen waeren frei verfuegbare Build-Maschinen fuer entwickler. Und zwar vor allem unter Windows, vielleicht auch noch OS X. Denn dann kann der Entwickler testen und buendeln, ohne sich eine entsprechendes System zulegen zu muessen. Auf der EuroPython in Birmingham (2010 glaube ich) gab’s mal einen Vortrag dazu, habe davon aber nie wieder was gehoert. Diez
Ich hab im Forum nachgefragt, wie man denn am Besten ein End-User Programm anbieten sollte, siehe:
http://www.python-forum.de/viewtopic.php?f=1&t=35061
Das wird ja spätestens dann kompliziert, wenn man externe Module nimmt. Aber auch wenn es nur eine simple .py Datei ist: Wie einem Otto-Normalo-Windows-Benutzter beibringen, wie man das nun nutzten kann?!?
Eigentlich gibt es da nicht wirklich was. Der Königsweg:
1. Paket in alle Linux Distributionen bringen 2. Für Windows, Mac: Tools wie PyInstaller, cx-freeze nutzten
Schön und gut. Funktioniert aber nur, wenn man reichlich man-power hat. Denn das ist alles viel Arbeit. Zumindest wesentlich mehr als sein Programm nur im PyPi zu registrieren und hoch zu laden...
Ich hätte da eine Idee: "PyPi-GUI"
Ist eine Art Synaptic für Python Pakete:
* Zielgruppe sind Endanwender, die gern ein Programm nutzten wollen * PyPi-GUI selbst per PyInstaller, cx-freeze anbieten * Bei der Installation wird ein Python Interpreter installiert, wenn nicht vorhanden * Mit PyPi-GUI kann man dann den PyPi durchsuchen * z.B. gefiltert nach: Intended Audience :: End Users/Desktop * Programm auswählen und installieren: * Es wird ein virtualenv erzeugt * Paket per pip installiert * Update erfolgt via pip --upgrade
Wenn es sowas gäbe, bräuchten Entwickler von End-User-Programmen nur sein Paket im PyPi hoch zu laden (Was ja ohne großen Aufwand geht). Dann eine kurze Anleitung aufzeigen: A. PyPi-GUI installieren B. Programm auswählen und installieren
Der Entwickler kann somit auf egal welcher Plattform arbeiten und jeder End-Anwender kann auf allen Plattformen das Programm auf einfacher Weise installieren und nutzten.
Da virtualenv genutzt wird, wird A die globale Python Installation sauber gehalten und B kann man das ganze auch einfach wieder Löschen...
Das ganze habe ich auf bei https://github.com/pypa/packaging-problems/issues/57 in die Runde geworfen.
Das Problem ist allerdings: Ich habe werde von PyInstaller, cx-freeze Erfahrungen und habe GUIs eigentlich immer nur mit TkInter gebaut. Wobei das letztere ja auch vollkommen reichen kann. Evtl. ist TkInter auch eine gute Idee, weil es ja quasi bei CPython mit installiert wird (unter Windows)...
Auf langer Sicht gesenen, wäre es natürlich super, wenn es das schon direkt in Python dabei ist. Aber das ist ja ein weiter, weiter Weg...
Irgendwelche Anmerkungen/Ideen hier???
Mfg.
Jens
_______________________________________________ python-de maillist - python-de@python.org https://mail.python.org/mailman/listinfo/python-de
Am 17.11.2014 um 20:17 schrieb Diez B. Roggisch:
Das faengt schon mal damit an, dass ich deine Annahme, man muesse als Entwickler ja nur eine Version bereitstellen, in Frage stelle. Schon simple Pfadoperationen koennen schief gehen, wenn man nicht wenigstens mal testes auf einer nicht-windows bzw. unixoiden Plattform. Auch einfache GUI-Anwendungen mit Tkinter sehen unterschiedlich aus. Das mag man tolerieren, wenn man aber ein bisschen Qualitaetskontrolle ausueben will, zwingt einen auch das dazu, sich auf den verschiedenen Plattformen ein Bild zu machen.
Das sind aber Punkte die für den Entwickler der Applikation wichtig sind, aber nicht direkt was mit einer PyPi-GUI zu tun hat. Wobei, wenn ich PyPi-GUI anfange, werde ich Tkinter nutzten. Das die GUI anders aussieht (meist schlechter) als nativ GUIs, stört mich auch, würde ich aber dann in Kauf nehmen...
Nehmen wir an, das wurde gemacht, das Paket kann fuer alle Zielplattformen verwandt werden. Dann ist das, was du dort vor hast, in meinen Augen immer noch nicht schluessig.
Denn es geht an den jeweiligen Nutzungsgewohnheiten der User vorbei. Die laden sich einen Installer runter, und fertig. Das willst du jetzt aendern, sie sollen eine Art "App-Store” verwenden, der aber noch extra zu installieren ist - durchaus schon eine Huerde.
Das stimmt, es ist dann sowas wie ein Python-App-Store. Ist ungewöhnlich, ja.
Aber dann geht es erst richtig los. Denn die App meiner Usertraeume braucht Qt5, Numpy und wasweisich. Alles Dinge, die sich *nicht* ueber pip instalieren lassen (unter Windows zumindest mal), noch dicke Library-Abhaengigkeiten haben, die man extra installieren muss usw. Da musst du dann passen, und am Ende landet man bei einem Bruchteil an Programmen, fuer die das alles wirklich funktioniert.
Das ist natürlich ein Problem. Aber eigentlich mehr eins für pip und Co. Ich weiß nicht, wie viel Programme sich wirklich mit pip installieren lassen. Aber ich schätze, für einen Entwickler ist es einfacher sein Programm per pip installierbar zu machen, als einen Installer für Linux, Mac und Windows bereit zu stellen...
Darum finde ich die Ansaetze von cx_freeze & Co schon durchaus gelungen: auf einer Entwicklermaschine finden sich all die Abhaengigkeiten, die man braucht. Alles, was dann “nur” noch bleibt ist das zusammensammeln.
OK, aber wie geschrieben: cx-freeze und PyInstaller benötigen die jeweilige Platform und wer hat schon Linux, Mac und Windows zur Verfügung...
Was halt wirklich helfen wuerde in meinen Augen waeren frei verfuegbare Build-Maschinen fuer entwickler. Und zwar vor allem unter Windows, vielleicht auch noch OS X. Denn dann kann der Entwickler testen und buendeln, ohne sich eine entsprechendes System zulegen zu muessen. Auf der EuroPython in Birmingham (2010 glaube ich) gab’s mal einen Vortrag dazu, habe davon aber nie wieder was gehoert.
Das wäre natürlich auch toll. Sowas wie travis-ci.org für unittests... Aber das ganze könnte sich auch ergänzen, wenn die generierten Installer auch bei PyPi landen, wäre es auch denkbar, das man diese per PyPi-GUI nutzt. -- Mfg. Jens Diemer ---- http://www.jensdiemer.de
participants (3)
-
Diez B. Roggisch -
Jens -
Jens Diemer