Das deutsche Python-Forum

...oder distribution von Python Programmen für Otto-Normale-Endanwender unter Linux/Windows...

Wie macht ihr das?

Erst hatte ich nur ein Projekt. Lib war direkt dabei: Downloaden, auspacken, starten, fertig. (Wenn Python installiert und im Pfad ist)...

Nun ist ein zweites Projekt gestartet, welches die selbe Lib braucht. Und nun?

Klar, theoretisch:
1. git repo mit lib
2. git repo mit Programm A
3. git repo mit Programm B

somit drei PyPi Pakete...


Und wie nun Otto-Normal-Tauglich das Programm anbieten???


Wenn alles im Linux-Distributions-Paketmanagement drin ist, kein Problem. Aber was ist, wenn nicht? Was ist mit Windows User?

Deswegen nutzte ich z.B. http://photobatch.stani.be nicht unter Windows. Die Installation ist der totale Krampf, siehe: http://photobatch.wikidot.com/install#toc8 (gut hier kommen noch externe Binärmodule erschwerend hinzu)


Wer kennt vorbildliche Beispiele? oder eine Best-Practise Anleitung?


In meinem Fall ist das noch alles pure-Python ohne externe Module. Von daher erscheint es für mich am Einfachsten, ich packe alles in ein git Repo und fertig. Hätte den Vorteil, das man es direkt als .zip von github ziehen könnte und gut...

Deluxe Version ist sicherlich einen richtigen Installer für Windows zu bauen und Pakete für verschiedene Linux Distributionen zimmern.
Aber das ist richtig viel Arbeit. Gerade das ständige Updaten...


Es müßte irgendwie eine Art Dummuser-pip-GUI Programm geben. Das dann starten, auswählen was man installieren will und er erstellt ein VirtualEnv mit allen Abhängigkeiten und legt Starter/Verknüpfung an.

Wie ist eigentlich der letzte Stand zum Thema Windows distribution???

py2exe wurde erst kürzlich aktualisiert und gibt es nun auch für Python3: https://pypi.python.org/pypi/py2exe

Ich mag es eigentlich nicht so ganz. Aber seien wir ehrlich, das ist Dummusertauglich, oder?

Also alles außer einer exe-Datei (bestenfalls noch mit Installer, z.B. NSIS) halte ich für völlig unbenutzbar unter Windows.
Man kann ja nicht von den Leuten erwarten, dass sie immer wissen, in welcher Programmiersprache etwas geschrieben ist, und wie man das installiert. Selbst erfahrene Leute haben dann oft keine Lust mehr.
(Beispiel: Wenn man mir ein Ruby-Programm im Quelltext geben würde, müsste ich mir erstmal Ruby herunterladen, gucken wie man die Bibliotheken installiert, dann habe ich keine Verknüpfung im Startmenü usw...)

Für Linux ist es natürlich schwieriger. Ich würde allerdings eventuell doch schauen, ob man da nicht ein Paket erstellen kann. Kann man das nicht sowieso automatisieren, wenn man eine neue Programmversion hat? Bei Arch Linux muss man z.B. einfach nur die Versionsnummer in der PKGBUILD verändern und dann wird das neue Paket gebaut.

@Hellstorm: Für Linux würde ich `pip` empfehlen. ``pip install my-wonderful-python-thing`` sollten Linuxbenutzer in der Lage sein einzugeben. Das ist unabhängig von der Linux-Distribution, wovon es ja auch einige gibt, für die man dann jeweils Pakete im richtigen Format erstellen müsste.

Bei Windows wäre eine MSI-Datei vielleicht noch eine Option.

BlackJack hat geschrieben:@Hellstorm: Für Linux würde ich `pip` empfehlen. ``pip install my-wonderful-python-thing`` sollten Linuxbenutzer in der Lage sein einzugeben. Das ist unabhängig von der Linux-Distribution, wovon es ja auch einige gibt, für die man dann jeweils Pakete im richtigen Format erstellen müsste.

Hm, Python-Nutzer sollten das können, aber allgemeine Linux-Nutzer nicht, denke ich. Mal wieder den Blick auf andere Programmiersprachen: Bei Ruby gibt es auch einen Befehl, oder? Oder bei Haskell? Aber die kenne ich ja nicht, weil ich mich damit nicht beschäftige.
Insbesondere da man bei Linux doch meistens davon ausgeht, dass die Software im Paketmanager enthalten ist. Es ist ja immer etwas inkoheränt, wenn man die meiste Software aus dem Paketmanager installieren sollte, und andere nicht. Ich halte es auch für nicht so gut, wenn der Anwender wissen muss, in welcher Sprache die Software geschrieben ist.

Das ist ja eben das große Problem bei Linux. Offtopic: Daher nehme ich auch Arch, da gibt es ja doch extrem viel Software entweder in den offiziellen Quellen, oder zumindest im AUR, so dass ich letzten Endes fast alles vernünftig durch den Paketmanager installieren kann.


Das ist jetzt natürlich alles auf „normale“ Anwendersoftware bezogen, die der Anwender einfach nur benutzen soll. Aber ich glaube, da spricht jens ja von.

@Hellstorm: Bei Ruby heisst der Paketmanager `gem`, bei Haskell benutzt man `cabal`. Der Klassiker `cpan` für Perl ein, und `npm` for Node.js. Dann gibt's noch `sbt` für Scala und `leiningen` für Clojure.

Auch wenn ein *Linux*-Nutzer das nicht kennen muss, würde ich schon erwarten das die damit zurecht kommen wenn das in einer README steht. Vielleicht ist mein Bild da auch falsch, ich habe halt den klassischen Unix-Nutzer im Kopf der Software auch mit `make` installieren kann wenn's das nicht als fertiges Paket gibt und technische Anleitung liest und umsetzt.

Für reine Mausschubser müsste man dann natürlich ein Distributions-Paket erstellen. Aber dann ist die Frage für welche Distribution und welche Version davon.

Genau, und die Paketmanager muss ich alle kennen, nur weil ich irgendein beliebiges Programm installieren möchte?

Es ist halt die Frage, für welche Zielgruppe man Linux sieht:

1. Das klassische Bild vom Computernutzer = Programmierer, wie es vor dem Aufkommen der PCs wohl der Fall war. Da ist das natürlich kein Problem, wobei ich auch für diese Leute Paketmanager praktischer finde. Wieso immer erst die README lesen, wenn man es auch mit einem immer gleichen Befehl installieren kann?

2. Otto-Normal-Benutzer (zwar technisch etwas interessierter, sonst würde er kein Linux nutzen , aber kein Programmierer), für den das Machen im Vordergrund steht, nicht unbedingt das Wie.


Man kann jetzt natürlich sagen, dass Linux primär ein Betriebssystem für 1) ist, was im Grunde nicht schlimm ist. Man hat nur ein anderes Problem: Nachwuchs. Kein Mensch ist als Computerexperte geboren, und als Kind spielt man daher erst einmal mit etwas herum, was man zumindest teilweise bedienen kann und versteht.

Ist halt die Frage, ob man als Kind eine englische README lesen und verstehen kann (Ich habe damals mit 12, 13 Jahren versucht mir einen VDR zu installieren... Mit schlechten Englischkenntnissen ALSA und die LinuxTV-Treiber selbst zu kompilieren war schon... abenteuerlich, um es mal kurz zu sagen. Was ich da überhaupt gemacht habe, hab ich absolut nicht verstanden).

Nur wenn Kinder und Jugendliche eben nicht mal einfache Programme, die sie haben wollen, installieren können, dann werden diese Leute wahrscheinlich auch in Zukunft kein Linux nutzen, selbst wenn sie es dann verstehen könnten. Sondern eben Windows oder Mac OS. Und so verliert man dann potentielle Programmierer

@Hellstorm: Nein die Paketmanager musst Du nicht alle kennen sondern die Installationsanleitung lesen und im Normalfall nur das befolgen was dort drin steht. Ohne das geht es schlicht nicht, ausser jemand anderes hat ein Paket für Deine Linuxdistribution erstellt *und* die ist normal im Repository vorhanden. Sonst braucht man eine Anleitung wie man eine andere Paketquelle hinzufügt, was dann normalerweise irgendwo als README auf englisch beschrieben ist. Jemand der keine README lesen kann oder will soll die Finger vom Rechner lassen oder muss halt mit dem klarkommen was wirklich idiotensicher und vorgekaut daher kommt.

Man kann Programme unter ”Linux” nicht immer mit dem gleichen Befehl installieren weil es da ja auch verschiedene Paketmanager gibt. Das würde für den Programmierer ja bedeuten er müsste Pakete für alle gängigen Distributionen in verschiedenen Versionen erstellen und testen. Aus Programmierersicht stellt sich da die Frage ob man dafür wirklich Zeit aufwenden möchte. Dann landet man bei der Frage womit man mehr Leute erreicht, einem Python-Paket mit ``setup.py`` die sich per `pip` auf fast jeder Python-Distribution installieren lässt, oder mit einem Paket für die Distribution(en) die man selber benutzt, die dann aber auch nur dort wirklich funktionieren. Und da denke ich eine allgemeine, distributionsunabhängige Installation ist besser. Wenn die Software etwas taugt, dann werden sich schon Maintainer finden die Pakete für die verschiedenen Distributionen daraus schnüren.

Das Nachwuchsproblem sehe ich nicht, beziehungsweise nicht was daran neu sein sollte. Leute die sich für Sachen unter der Haube interessieren schauen da von sich aus mal drunter. Leute die ”gezwungen” werden unter die Oberfläche zu schauen, suchen sich entweder ein anderes System, oder es weckt ihr Interesse.

Ja man kann als Kind (13+) eine englische README lesen und verstehen. Wer das nicht kann oder gewillt ist es zu lernen kommt als potentieller, allgemeiner Programmierer unter Linux sowieso nicht in Frage, denn da muss man deutlich kompliziertere Sachen lesen und verstehen als eine README in der man aufgefordert wird ein ``pip install irgendwas`` einzugeben. Und der Vergleich davon mit dem selbstkompilieren von Kerneltreibern hinkt auch ein kleines bisschen.

@Jens:
Ich würde von der Zielgruppe abhängig machen. Dem geneigten User unter Windows kann man die Instandhaltung eines shared lib-Pools durchaus zumuten. Da Du aber von ottonormal sprachst - unter Windows bedeutet das eher "Ich weiss wie der Computer angeht und wie ich meine Emails im Browser schreibe", während unter Linux die Leute eher auch mal den Blick auch unter die Haube wagen und früher oder später die Console entdecken.

Die standalone + Klickinstall Philosophie im Windowsland führt zwar dazu, dass Du unter Umständen Deine Bibliothek in zwei verschiedenen Anwendungen quasi doppelt paketiert ausliefern musst, allerdings entstehen so kaum Interferenzen zwischen den Anwendungen. Unter Linux hingegen führt durch die shared Philosophie eine unsachgemässe Installation schnell mal dazu, dass die Hälfte der gelinkten Anwendungen nicht mehr funktionieren. Bei Letzterem habe ich desöfteren im Bekanntenkreis schon Feuerwehr spielen dürfen.

Die spracheigenen Paketmanager würde ich ausserhalb der "Sprachszene" generell nicht voraussetzen. So ist z.B. die Kombination aus virtualenv + pip auch für Linuxnutzer, welche "nur" den Standarddistributionsweg nutzen, ungewöhnlich. Die Bereitschaft, sich darauf einzulassen, ist wahrscheinlich höher als bei Windowsnutzern.

BlackJack hat geschrieben:@Hellstorm: Nein die Paketmanager musst Du nicht alle kennen sondern die Installationsanleitung lesen und im Normalfall nur das befolgen was dort drin steht. Ohne das geht es schlicht nicht, ausser jemand anderes hat ein Paket für Deine Linuxdistribution erstellt *und* die ist normal im Repository vorhanden. Sonst braucht man eine Anleitung wie man eine andere Paketquelle hinzufügt, was dann normalerweise irgendwo als README auf englisch beschrieben ist. Jemand der keine README lesen kann oder will soll die Finger vom Rechner lassen oder muss halt mit dem klarkommen was wirklich idiotensicher und vorgekaut daher kommt.

Ich finde deine Einstellung irgendwie komisch. Soll kein Angriff sein, aber das ist die typische „Linux (=Alle Distributionen als Gesamtsystem gesehen) ist so gut, weil ich es ohne Probleme benutzen kann und andere das auch so können müssen“-Einstellung.
Wo ist denn das Problem mit Vereinfachung? Ist man dann nicht mehr so elitär, oder was?

Das ist meiner Meinung nach ein starker Grund, wieso Linux nicht aus der Nischen-Ecke herauskommt. Wenn Distributionen wie Ubuntu versuchen, das mal etwas einfacher zu machen, dann scheint es ja doch erfolgreich zu sein.

BlackJack hat geschrieben: Man kann Programme unter ”Linux” nicht immer mit dem gleichen Befehl installieren weil es da ja auch verschiedene Paketmanager gibt. Das würde für den Programmierer ja bedeuten er müsste Pakete für alle gängigen Distributionen in verschiedenen Versionen erstellen und testen. Aus Programmierersicht stellt sich da die Frage ob man dafür wirklich Zeit aufwenden möchte.

Das ist doch genau das Problem! Unter Windows und Mac haben die Entwickler doch keine Probleme, ein Installationspaket zu erstellen, weil man eben grob nach dem Gesichtspunkt „Bei mir läufts, deswegen läuft es woanders auch“ vorgehen kann. Dass es für den Programmierer unter Linux zu schwer ist, all die Distributionen zu berücksichtigen, ist mir auch klar. Da ist jetzt nur die Frage, ob man deswegen dann einfach nur den Quelltext verbreiten sollte, oder ob man vielleicht einfach mal etwas an dem System mit den fragmentierten Paketmanagern etwas ändern sollte?
Es gab doch auch schon andere Standardisierungen unter Linux, z.B. DBUS oder diese .desktop-Dateien. Wieso sollte das nicht auch mit Programminstallationen gehen?
Das Problem würde übrigens so um 2005 mal angegangen (Wie hieß das noch gleich, Autoinstall oder so?). Hat sich leider nicht durchgesetzt...

BlackJack hat geschrieben: Das Nachwuchsproblem sehe ich nicht, beziehungsweise nicht was daran neu sein sollte. Leute die sich für Sachen unter der Haube interessieren schauen da von sich aus mal drunter. Leute die ”gezwungen” werden unter die Oberfläche zu schauen, suchen sich entweder ein anderes System, oder es weckt ihr Interesse.

Ja man kann als Kind (13+) eine englische README lesen und verstehen. Wer das nicht kann oder gewillt ist es zu lernen kommt als potentieller, allgemeiner Programmierer unter Linux sowieso nicht in Frage, denn da muss man deutlich kompliziertere Sachen lesen und verstehen als eine README in der man aufgefordert wird ein ``pip install irgendwas`` einzugeben. Und der Vergleich davon mit dem selbstkompilieren von Kerneltreibern hinkt auch ein kleines bisschen.

Hier hast du auch wieder eine komische Auffassung, meiner Meinung nach. Ich weiß nicht ob du ein Wunderkind bist, aber mit 13 Jahren richtige englische Texte zu verstehen ist meiner Meinung nach absolut nicht möglich. Guck dir doch mal an, was man nach 3 Jahren in der Schule mit Englisch gelernt hat? Und Englisch ist ja immer noch recht einfach für uns Deutsche. Was macht denn ein Russe oder ein Koreaner, das ist für die doch ein Ding der Unmöglichkeit. Man schlägt sich da vielleicht mal so durch, aber wirklich verstehen?

Interesse daran, den Sachen unter die Haube zu sehen, kommt doch erst mit der Zeit. Niemand kriegt als Kind einen Computer vorgesetzt und denkt sich „Boa, jetzt will ich aber mal schauen, wie man mit Assembler das Gerät programmiert“. Zuallererst benutzt man das Gerät und mit der Zeit entwickelt man Interesse an den zugrundeliegenden Technologien.

Ich sage nicht, dass das unter Windows sehr viel besser funktioniert. Unter Windows versucht man die Grundlagen komplett abzuschotten, so dass man meistens nicht mit den Grundlagen in Kontakt gerät. Linux versucht das doch eher zu fördern. Aber bei Linux ist halt die Einstiegshürde derart groß, dass viele Leute überhaupt, bevor sie damit in Kontakt kommen können, bereits abgeschreckt werden. Man braucht dann ein derart dickes Fell, um das dann durchzuziehen. Und das haben die meisten Leute nicht, und das kann ich ihnen auch nicht verübeln.

Außerdem: Wieso werden Programme denn im Allgemeinen übersetzt? Ich finde das arg merkwürdig. Die Benutzeroberfläche der Programme ist komplett lokalisiert, aber um das Programm installieren zu können, braucht man dann wieder Englisch, weil man sonst die README nicht versteht. Ich verstehe da nie, wieso die Projekte die README nicht durch die Übersetzer übersetzen lassen und dann eine README.de usw. erstellen.
Bei Android wird die Beschreibung im Play Store doch auch übersetzt, nur bei Linux-Software nie.

Ja, ist alles nicht so einfach

PIP ist schon nett. Aber ohne ein wenig drum herum auch doof: geht erstmal nur unter Linux 'einfach' wenn es denn installiert ist. Aber müllt erstmal deine Python Installation zu

Und für Windows user ist das eh nix. Denke da wird es auf py2exe hinaus laufen, auch wenn ich das auch suboptimal finde...

In der zwischenzeit habe ich mein bootstrap_env verbessert, so das es auch unter Windows nutzbar ist.

Anleitung für windows sieht dann so aus: https://github.com/DWLOAD/DwLoadServer#windows
Für Linux so: https://github.com/DWLOAD/DwLoadServer#linux

Vorteil ist halt, das man mit einem nackten Python Installation loslegen kannst und das halt ein virtualenv erstellt wird.

Für dummuser ist das aber nix...

@Hellstorm: Ich sehe an meiner Einstellung nichts Elitäres. Ich sage ja auch nicht, dass das so bleiben muss, aber im Moment *ist* es halt so. Distributionen vereinfachen es für Anwender die nicht so stark in das System eindringen wollen oder können. Das ist gut. Ändert aber nichts daran dass man das machen muss wenn man die schöne paketierte Welt seiner Distribution verlässt. *Dann* muss man in die READMEs schauen und verstehen was die einem sagen. Wobei wie gesagt ein ``pip install irgendwas`` IMHO keine unüberwindbare Hürde darstellt für einen denkenden Menschen der etwas installieren möchte. Zumindest keine grössere Hürde als eine README oder Webseite wo steht wie man zum Beispiel ein PPA einbindet und den Schlüssel um die Signatur zu prüfen, um dann ein Paket aus einer Fremdquelle zu installieren. Das ist ja auch nicht einfacher.

Das mit der Nischen-Ecke ist Unsinn (nicht nur als redundanter Begriff ). Das Linux auf dem Desktop nicht verbreitet ist hat nichts mit benutzer(un)freundlichkeit zu tun, sondern ganz wesentlich mit a) Windows ist überall vorinstalliert, b) das (fehlende) Spieleangebot, und c) die fehlende Herstellerunterstützung von Hardware jenseits von dem was entweder supereinfach unterstützt werden kann oder was auch in Servern verbaut werden kann. Auf Server- und Embedded-Seite sehe ich Linux nicht als Nischenprodukt.

Unter Windows und Mac gibt es weniger Probleme Installationspakete zu erstellen weil zumindest unter Windows üblich ist für jedes Programm immer *alles* an Abhängigkeiten mit in den Installer zu packen und das man einen Prozessor aus der x86-”Familie” voraussetzen kann. Hatte im letzten Beitrag gar nicht dran gedacht weil es für reinen Python-Code keine Rolle spielt, aber wenn man Pakete schnürt muss man ja nicht nur verschiedene Distributionen und deren Versionen sondern auch noch Hardwareplattformen berücksichtigen, was die Anzahl der zu erstellenden und testenden Pakete noch mal multipliziert. Die Sache mit den Bibliotheken ist jedenfalls unter Linux fundamental anders, das man eben nicht alles statisch linkt oder Bibliotheken immer mit jedem Programm mitliefert, und ich sehe auch nicht das sich das ändern wird. Halte ich auch nicht für sinnvoll das zu ändern.

Ich denke nicht das ich ein Wunderkind war. Ich habe in dem Alter angefangen und damals gab es deutlich weniger Spiele die lokalisiert waren, also musste man sowohl die Spieloberfläche als auch die Anleitungen auf Englisch lesen. Wenn man nach drei Jahren nicht in der Lage ist den Aufbau von englischen Sätzen zu verstehen und Worte die man nicht kennt in einem Wörterbuch nachzuschlagen, dann kann der Unterricht nichts getaugt haben. Es geht ja nicht darum englische Prosa zu lesen und Anspielungen, Andeutungen, und Wortspiele zu verstehen, von Autoren die bemüht sind die Möglichkeiten ihrer Muttersprache Sprache voll auszuschöpfen um literarische Meisterwerke zu schaffen, sondern um in der Regel recht simpel gestrickte und schnörkellos formulierte technische Texte. Oft von Leuten die auch eine andere Muttersprache als Englisch haben.

Das was Du als meine Auffassung bezeichnest ist nicht *meine* Auffassung, sondern Realität. Ohne englische Texte lesen zu können, stösst man nun mal schnell an Grenzen wenn man Informationen rund ums Programmieren sucht. Da kann ich nichts dafür. Dafür dass das Russen oder Koreaner vielleicht härter trifft ist auch nicht meine Schuld.

Programme werden lokalisiert weil die Anwender nicht alle Englisch können. Die READMEs sind im Zweifelsfall für Programmierer, und die können alle Englisch, denn sonst könnten sie nicht sinnvoll programmieren. Reine Anwender benutzen schliesslich die Paketverwaltung ihrer Distribution.

Hm. Das ist ein wenig wiedersprüchlich

Zum installieren muß man die README schauen, aber:

BlackJack hat geschrieben:Programme werden lokalisiert weil die Anwender nicht alle Englisch können. Die READMEs sind im Zweifelsfall für Programmierer, und die können alle Englisch, denn sonst könnten sie nicht sinnvoll programmieren. Reine Anwender benutzen schliesslich die Paketverwaltung ihrer Distribution.

@jens: Wo ist der Widerspruch? Um ein Paket aus der Paketverwaltung der Distribution zu installieren braucht man ja nicht in die README in einem Quelltextarchiv schauen. Wenn man das allerdings machen will oder muss, dann sollte man besser englisch können.

Naja, gilt halt nur für Programm die schon in der Distribution vorhanden ist.

Hier geht es um kleinere Python Programm, für die einfach die Man-Power fehlt für alle möglichen Distributionen Pakete zu schnüren und um sich darum zu kümmern, das die Pakete auch in den verschiedenen Distributionen aufgenommen werden...

Habt ihr eigentlich schon mal gesehen, wie einfach es ist, in PyCharm PyPi Pakete zu installieren?

Das bringt mich auf eine Idee: Warum nicht eine einfache Otto-Normalo-taugliche GUI um PyPi Pakete zu installieren?
Dabei kann dann wahlweise ein frisches virtualenv aufgezogen werden. So kann man x-beliebige Python Programme installieren und wieder in die Tonne hauen...

Dieses PyPi-GUI sollte aber selbst sehr einfach zu installieren sein. Vielleicht für Windows dann ein py2exe nutzten?

Wenn es sowas geben würde, dann wäre es für jeden Python Entwickler leicht einen Benutzer zu erklären, wie er sein Programm mal eben installieren kann:
1. Installiere PyPi-GUI, siehe Anleitung da-irgendwo...
2. Wähle mein Programm aus und installiere es

Wäre schön wenn diese fiktive PyPi-GUI folgendes kann:
* Basics: PyPi pakete installieren/löschen
* Starter anlegen: .desktop Dateien für Linux, Verknüpfungen für Windows (Oder gleich ein allgemeinen Starter bieten)


EDIT: Hab mal gesucht und das gefunden:
https://pypi.python.org/pypi/PyPI-Browser/ - PyQt4 basierender Browser, der anscheinen nicht installieren kann.
https://pypi.python.org/pypi/pulpitum/ - PyPI client for Humans™ - GitHub Account existiert nicht mehr, tot?

Ich hab es mal bei https://github.com/pypa/packaging-problems/issues/57 in den Raum geworfen...

@jens: Ich denke das wird daran scheitern das die Zielgruppe GUI-Programme ”braucht”, man aber mit `pip` sicher keine GUI-Toolkits + Python-Anbindung installieren kann/will. Was sollten die sich also mit diesem Programm installieren? Kommandozeilenprogramme wo sie dann doch wieder lesen müssten, sehr wahrscheinlich englische Texte?

BlackJack hat geschrieben:@jens: Wo ist der Widerspruch? Um ein Paket aus der Paketverwaltung der Distribution zu installieren braucht man ja nicht in die README in einem Quelltextarchiv schauen. Wenn man das allerdings machen will oder muss, dann sollte man besser englisch können.

Das würde aber heißen, dass ich als Anwender bloß keine Programme benutzen darf, die nicht in der Paketverwaltung sind. Das ist doch total komisch. In der Paketverwaltung sind doch praktisch immer nur große und weitverbreitete Programme. Darf ich als normaler Anwender nur solche Programme nutzen?

Mal ein reales Beispiel:

Ich würde jetzt beispielsweise ein kleines Programm schreiben, was mir japanische Jahreszahlen in deutsche Jahreszahlen umwandelt (Praktisch das hier: klick).

Das ist schon ziemlich speziell und würde es wohl deswegen höchstwahrscheinlich nicht in die Paketverwaltung von Ubuntu, OpenSUSE, Fedora oder ähnliches schaffen. Trotzdem gibt es einige Anwender, die genau das Programm haben wollen. Dürfen die das jetzt nicht verwenden, nur weil die Zielgruppe des Programms zu klein ist und es nicht in der Paketverwaltung ist? Müssen die Leute sich erst README-Dateien auf Englisch durchlesen, die ja für Programmierer geschrieben sind, nur weil sie das Programm einfach nur benutzen wollen?
Es gibt unter Windows zig dieser kleinen Tools, die einfach nur eine ganz kleine Aufgabe haben, die aber trotzdem jeder Anwender ohne irgendwelche Probleme installieren kann. Und unter Linux ist es praktisch immer absolut unmöglich, als Laie so ein Programm zu installieren. Das wäre etwas ganz anderes, wenn die Paketmanager vereinheitlicht wären und der Autor des Programmes ein Paket (praktisch wie er es auch mit PyPi oder ähnliches machen würde) vorbereitete und der Anwender klickt dann doppelt darauf und es installiert sich automatisch.

Dass es mit einem Paketmanager auch gut klappen kann, sieht man doch unter Android. Der Autor erstellt eine APK, und jeder Idiot kann sich das Programm installieren.

Und genau deswegen ist Linux auf dem Desktop nur in der Nischenecke. Ich sehe das doch bei meinem Vater. Er wollte mal Linux ausprobieren, kann aber nicht wirklich Englisch. Am Anfang ist es zwar einfach, aber wenn er mal etwas installieren möchte, was nicht in den Paketquellen ist, wird er scheitern.

Ich glaube du kannst dir nicht vorstellen, wie schwierig es für den Otto-Normal-Benutzer ist, ein Programm unter Linux zu kompilieren und zu installieren. Und diese Leute sind nicht dumm, sondern sie haben einfach nur keine Lust, sich derart mit Computern zu beschäftigen wie unsereins das tut. Dafür können sie etwas anderes besser. Da sehe ich nicht, wieso man solche Leute herablassend als Maus-Schubser und ähnliches bezeichnen sollte.

Naja, wobei gerade wegen der Paketverwaltung ist Linux als Desktop System für Otto-Normal-Anwender interessant. Diese sollten dann allerdings nur Programme aus der Paketverwaltung nehmen...

Hellstorm hat geschrieben:Ich würde jetzt beispielsweise ein kleines Programm schreiben, was mir japanische Jahreszahlen in deutsche Jahreszahlen umwandelt (Praktisch das hier: klick).

Das ist schon ziemlich speziell und würde es wohl deswegen höchstwahrscheinlich nicht in die Paketverwaltung von Ubuntu, OpenSUSE, Fedora oder ähnliches schaffen.

Es gibt IMHO keine Kritiken wie "Programm muß groß genug sein" oder "Programm muß viele Leute Ansprechen"...
Das Problem ist viel mehr: Du als Entwickler muß dein Programm genau so gestalten, das es den Richtlinien entspricht. Das kann schon recht umfangreich sein...


Meine Idee ist ja quasi, eine Insellösung: Eine Paketverwaltung für PyPi Module.
So brauchst du als Entwickler nur dafür sorgen, das dein Programm bei PyPi erscheint und das ist ja nicht wirklich schwer.

jens hat geschrieben:Meine Idee ist ja quasi, eine Insellösung: Eine Paketverwaltung für PyPi Module.
So brauchst du als Entwickler nur dafür sorgen, das dein Programm bei PyPi erscheint und das ist ja nicht wirklich schwer.

Ich find die Idee gut, aber in Sachen Umsetzbarkeit einer Point&Klick-Installationslösung wären da eine Menge Unwägbarkeiten zu umschiffen:

- Taugt PyPi mit pip von der Funktionalität her für eine benutzerfreundliche GUI-Lösung? Oder brauchts einen neuen Paketstandard? Z.B. möchte der Laie vllt. nur die "ausführbaren" Anwendungen kategorisiert sehen. Er interessiert sich nicht für Modul XY, im Gegenteil, die schiere Menge an Lib-Paketen verwirrt und er findet nix Brauchbares. Das ist ein Problem, mit dem die GUI-Paketverwaltungen unter Linux z.T. immernoch kämpfen.

- Dann kommen bei Python doch recht viele Pakete mit nativem Code. Wie soll das unter Windows verlässlich gehandhabt werden? MinGW mit ausliefern und on-the-fly den Compiler anwerfen? Config-Option, wo der Compiler/Python-Target eingestellt werden kann?

Gibt sicher noch Einiges mehr...

jerch hat geschrieben:- Taugt PyPi mit pip für eine benutzerfreundliche GUI-Lösung? Z.B. möchte der Laie vllt. nur die "ausführbaren" Anwendungen kategorisiert sehen. Er interessiert sich nicht für Modul XY, im Gegenteil, die schiere Menge an Lib-Paketen verwirrt und er findet nix Brauchbares. Das ist ein Problem, mit dem die GUI-Paketverwaltungen unter Linux z.T. immernoch kämpfen.

Das ist kein Problem, es gibt es jede Menge Meta-Daten zum filtern, z.B.: die classifiers:
https://pypi.python.org/pypi?%3Aaction=list_classifiers

z.B.: Intended Audience :: End Users/Desktop

jerch hat geschrieben:- Dann kommen bei Python doch recht viele Pakete mit nativem Code. Wie soll das unter Windows verlässlich gehandhabt werden? MinGW mit ausliefern und on-the-fly den Compiler anwerfen? Config-Option, wo der Compiler/Python-Target eingestellt werden kann?

Kann sein... Aber das ist ein Problem von pip