Mailinglisten-Archive |
On Sam, 02 Feb 2002, Alexander Merz wrote: > > nutze. Duerfte auch mit dem Konzept von PEAR zusammenhaengen, > > bzw. mit dem, was bis jetzt erkennbar ist. > Was stört dich? Um dies zu beantworten, habe ich mir nun erstmal das aktuelle Manual sowie die FAQ durchgelesen, schliesslich haette es sein koennen, dass die bisherige Kritik inzwischen nicht mehr gerechtfertigt ist - das letzte Mal hatte ich mich vor einigen Monaten damit beschaeftigt. Leider war dem nicht so... Vielleicht sieht in hoffentlich naher Zukunft alles wesentlich besser aus - die Grundsteine sind immerhin gelegt. PEAR teilt sich also auf in Basismodule, welche der PHP-Distribution beiliegen sollen, diese werden als der Kern bezeichnet. Weiterhin die erweiterten sowie PECL. So weit, so gut, doch hier faengt es bereits an. PECL sind PHP-Erweiterungen in C, die nicht den PEAR-Codierstandards entsprechen, waehrend in den als "Erweitert" bezeichneten Modulen einerseits PHP-Pakete oder auch PHP-Erweiterungen in C enthalten sein koennen, welche den PEAR Codierstandards entsprechen. Klingt fuer mich irgendwie chaotisch, bzw. fehlt ein Element - und zwar diejenigen PHP-Pakete, die nicht den PEAR-Codierstandards entsprechen. Wo ist Platz fuer diese? Vermutlich sollen sie nicht in PEAR aufgenommen werden - das waere im momentanen Konzept ja noch verstaendlich, aber weshalb existiert dann PECL fuer die entsprechenden PHP-Extensions in C? Abgesehen davon: Der Hauptkritikpunkt bezieht sich auf die Ordnung und (aktuelle) Distribution von PEAR bzw. der Bausteine von PEAR. Ich wuerde mir die Anwendung und Installation aehnlich wie der Module aus dem CPAN fuer Perl vorstellen. Dies gliedert sich wie folgt auf: - Modul herunterladen - Modul entpacken - perl Makefile.PL - make - make test - make install Noch einfacher geht's mit dem Modul CPAN, was eine Art Shell zur Installation zur Verfuegung stellt. Persoenlich ist mir jedoch die erste Methode irgendwie lieber - ich habe das Gefuehl, hier mehr Kontrolle zu besitzen. Etwaige Abhaengigkeiten von anderen Modulen werden beruecksichtigt, bzw. wird angegeben, welche Module noch benoetigt werden, falls noch nicht im System vorhanden. Jedes Modul ist dabei weitestgehend eigenstaendig, bringt neben dem eigenen Code auch eigene Dokumentation mit, welche ebenfalls mit installiert wird und sich durch perldoc oder auch man anzeigen laesst. Wie sieht es aus in PEAR? Wie besorge ich mir den Code? Momentan doch nur per CVS, oder? Zumindest falls das Paket nicht extern als Archiv zur Verfuegung gestellt wird, dies trifft jedoch bislang nur fuer PHP-Extensions zu, oder? Gehen wir mal ein wenig in die Zukunft und stellen uns vor, dass PEAR inzwischen als eigenstaendiger Zweig im CVS vorhanden ist, sowie dass einer PHP-Version nur noch die Kernpakete beiliegen. Nebenbei: Es muesste auch sichergestellt sein, dass jene installiert werden, ansonsten nuetzen einem die schoensten PEAR-Pakete, welche auf der Basis aufsetzen, rein gar nichts. Die Kernfrage: Gibt es ein Konzept, die PEAR-Pakete in aehnlicher Art und Weise wie die CPAN-Module zu installieren? Also: - PEAR-Modul besorgen - auspacken - (kompilieren, falls C enthalten) - moeglicherweise die Lauffaehigkeit testen - installieren Jene PEAR-Pakete muessten IMHO ebenfalls eigenstaendig sein, Beispiele sowie Dokumentation mitbringen. Also quasi das Gegenteil vom aktuellen Zustand, bei dem es einen Zweig im CVS fuer PEAR, und einen fuer das Manual gibt. Zwar freue ich mich, zu sehen, dass es beim Schreiben des Manuals einige Fortschritte gibt, aber ein grosses PEAR-Manual ist wie ich finde genau der falsche Weg. Vielmehr stelle ich mir eine Liste, sortiert nach verschiedenen Eigenschaften, der PEAR-Module vor, aus der man schliesslich das benoetigte Modul auswaehlen und herunterladen kann. Zugegebenermassen habe ich die PEAR-Mailinglisten nur am Rande verfolgt, kann daher nicht sagen, ob Derartiges geplant ist und irgendwann realisiert werden soll. Das PEAR-Manual duerfte jedoch nur die Kernmodule und allgemeinen Erlaeuterungen zu PEAR enthalten. Alle sonstigen PEAR-Pakete muessten sich selbst dokumentieren. Bleibt die Frage, was mit den Paketen passiert, deren Autor keine Dokumentation bereitstellt - nun, das Problem duerfte sich von selbst loesen. Entweder es findet sich jemand, der die Doku schreibt, oder das Modul ist ohne Doku bzw. nur anhand Beispielen nutzbar, oder das Modul wird eben nicht genutzt. Ein Aufbau des Manuals wie bei dem von PHP selbst, bringt jedoch meines Erachtens keinen Sinn. Ferner muessten viele Extensions, die momentan in PHP enthalten sind, in PEAR bereitgestellt werden. Die PHP-Distribution sollte ein wenig abgespeckt werden, heisst letztlich, es duerften keine neuen Extensions darin mehr Platz nehmen, sowie diejenigen, die z.B. am wenigsten benutzt werden, muessten in PEAR verlagert werden. Ist natuerlich nicht einfach, dies zu entscheiden - zugegeben. Darueber hinaus finde ich die flache, oder sogar sehr flache Hierarchie ein wenig ungluecklich. Wenn ich mir das CVS von PEAR ansehe (also nicht php4/pear, sondern nur wirklich nur pear), kann ich es fast nicht glauben. Da existiert auf einer, und zwar der obersten Ebene Net_CheckIP, Net_Finger, Net_Geo, Net_IPv6 usw. Ich wage mich gar nicht an die Vorstellung von PEAR, wenn sich in Zukunft viele Autoren mit ihren Modulen beteiligen. Vor allem sieht die Hierarchie in php4/pear noch anders aus. In welche Richtung wird sich PEAR hier bewegen? Vielleicht haengt der aktuelle Zustand von PEAR auch damit zusammen, dass PEAR hauptsaechlich von fortgeschrittenen Programmierern bzw. PHP-Kennern benutzt wird - wenn ueberhaupt. Ich finde, hier muesste der Schritt in Richtung "Normaluser" gehen (bloedes Wort, ich weiss, mir fiel nix Besseres ein ;-) ). Am Beispiel erklaert: X beauftragt Y mit dem Installieren eines Weblog-Systems. Y findet etliche Loesungen in PHP. Ok, PHP ist eine gute Sache (tm), laeuft bereits auf dem zu benutzenden Webserver, also los. Herunterladen, Entpacken, README von Produkt P lesen... Verzeichnis anlegen, Datenbank erstellen, ok. Nun braucht P Modul M1 und M2 aus PEAR, ist im README zu lesen. PEAR? Aha, eine Sammlung von PHP-Modulen... Und nun? CVS? Installation? An dieser Stelle beisst man sich entweder zeitraubend durch oder gibt auf. Bei Perl wuerde der Download von einigen wenigen Dateien mitsamt anschliessender, recht simpler Installation genuegen, und schon waeren die Voraussetzungen erfuellt. Noch ist der Begriff PEAR nicht so verbreitet und untrennbar mit PHP verbunden wie das CPAN bzgl. Perl. Und ehrlich gesagt wundert mich dies auch gar nicht. Wer mich jetzt unbedingt missverstehen mochte, wird dies sicherlich tun. Meine Kritik bezieht sich nicht auf den in PEAR enthaltenen Code, oder gar auf dessen Qualitaet. Auch die recht strengen Codierrichtlinien treffen nicht zwangslaeufig jedermanns Geschmack, aber darum geht es mir hier wirklich nicht. Die vielfach so gut wie nicht oder nur im Code vorhandene Dokumentation ist hingegen ein wesentlicher Schwachpunkt, selbst wenn daran gearbeitet wird, aber dazu habe ich mich ja bereits geaeussert. Mir ist zumindest noch kein CPAN-Modul ohne Dokumentation begegnet - vielleicht muesste auch ein Autor von PEAR-Modulen dazu "verdonnert" werden, Dokumentation bereitzustellen, ansonsten kann keine Aufnahme in PEAR erfolgen. Damit waeren wir bei einem weiteren Punkt, bei dem ich mich allerdings nicht recht entscheiden kann - der Frage, was in PEAR aufgenommen werden soll oder nicht, sowie wer dies bestimmt. Hier gehen die Meinungen ja sehr auseinander, manche plaedieren fuer die Aufnahme moeglichst vieler Module, auch wenn diese konkurrierende Loesungen darstellen wuerden, andere sind dafuer, pro Kategorie nur ein Paket bereitzustellen. Wenn ich mir das CPAN anschaue, gibt es auch dort Bereiche, in denen sehr viele Module vertreten sind, welche sich auch teilweise in der Funktionalitaet ueberschneiden. In anderen Kategorien existieren hingegen wenige oder es gibt einen (Quasi-)Standard. Ich denke, eher fuer die Pluralitaet von Modulen einzutreten, welche meines Erachtens besser ist als eine kuenstliche Beschraenkung vorzunehmen. Letztere wuerde bereits dann aufgehoben, wenn der Modulautor sein Werk nicht als Teil des offiziellen PEAR, sondern irgendwo zum Download veroeffentlicht und durch geeignete Verfahren (installer?) beim Benutzer in den PEAR-Baum gelangt. Ok, fuer eine erste Stellungnahme an einem Samstagnachmittag soll dies endlich genug sein. ;-) Beste Gruesse, Ralf -- : www : http://www.bttr.org : mail: ralf_(at)_bttr.org : Eine Site rund um MySQL : http://www.bttr.org/mysql/ : Privacy now! My Public Key : http://www.bttr.org/geschke.asc
php::bar PHP Wiki - Listenarchive