Der alltägliche CPAN-Kampf
Ich weiß, dass das CPAN-Archiv zu den größten Stärken Perls gehört. Trotzdem ertappe ich mich regelmäßig dabei, lieber selbst ein paar Zeilen zu schreiben als ein fertiges Modul dafür einzusetzen. Meine Abneigung gegenüber vorgefertigten Modulen hat mehrere Gründe:
- Bis ich die Dokumentation gelesen und verstanden habe, habe ich oftmals die Lösung selbst programmiert.
- Ich hasse Abhängigkeiten von fremdem Code. Ein CPAN-Modul, das tut, was ich jetzt benötige, ist wunderbar. Aber wehe ich brauche später Funktionen, die darüber hinausgehen. Dann ist doch wieder selber coden angesagt und in der Summe ist das meist mehr Aufwand.
- Die eingesetzten Module müssen überall dort verfügbar sein, wo mein Programm laufen soll. Das ist gerade auf Windows-Umgebungen oftmals ein Glücksspiel.
Diese Punkte mögen für den (Quasi-)Vollzeit-Programmierer unwichtig sein. Ja, im Gegenteil: Wer ständig am Coden ist, für den ist jedes gelernte Modul künftig eine große Zeitersparnis. Ich hingegen verbringe nur einen kleinen Teil meiner Zeit mit Programmierung, und dabei stelle ich regelmäßig fest, dass der Aufwand das Drumherum eines Projektes zu klären, den eigentlichen Programmieraufwand um ein Vielfaches übersteigt. Wenn ich mich also oft von Nicht-Core-Modulen fernhalte, dann ist das letztlich nichts anderes als die Umsetzung des Simplify-Prinzips. Lieber schreibe ich zwanzig Zeile Code und weiß, dass ich keine bösen Überraschungen erlebe, wenn das Programm später auch mal unter Windows laufen muss, als dass ich ein CPAN-Modul einsetze, das dann unter Windows nicht zu installieren ist.
Apropos Installationsprobleme: Ich wollte gestern auf meinem MacBook DBD::SQLite installieren. Der seit Jahren vertraute Weg über
perl -MCPAN -e shell
versagte, wie leider des öfteren. Ziemlich gefrustet und am Überlegen, was ich denn als Ersatz verwenden könnte, versuchte ich die manuelle Installation über die Kommandozeile:
perl Makefile.PL
make
make test
make install
Und zu meiner Verblüffung klappte die Installation dieses Mal problemlos. Woran das liegt? Keine Ahnung. Es ist ja nicht so, dass perl -MCPAN -e shell grundsätzlich ein Problem hätte; die meisten Module lassen sicht durchaus installieren, auch Module, die nicht nur aus Perl-Code bestehen. Aber halt nicht immer. Daher der Tipp an alle anderen Perl-Fans mit CPAN-Problemen: Wenn’s mal über die CPAN-Shell hakt, einfach auf der Kommandozeile von Hand versuchen.
Save This Page
Hallo Stefan,
bei wirklich einfachen Sachen, mag das noch ok sein, aber ich persönlich bin ein absoluter Freund von CPAN-Modulen. Wenn ein Bug drin ist, kümmern sich meist die CPAN-Autoren darum (zumindest wenn es kein altes Modul ist).
Ein Modul, dessen Dokumentation nicht innerhalb von ein paar Minuten schlüssig zum Ergebnis führt und eine eigentlich simple Sache machen soll, ist schlecht designt oder schlecht dokumentiert. Dann kann ich es durchaus verstehen wenn man lieber selbst etwas codet.
Eigene Erweiterungen kann man dann auch gerne an den Modul-Autor schicken - in der Hoffnung, dass es eingebaut wird.
Zum Thema Installation: Auf Perl-Community.de im Wiki gibt es einen ganz guten Artikel dazu: http://wiki.perl-community.de/bin/view/Wissensbasis/ModuleWieInstalliereIchEinModul
Welche Version von CPAN.pm verwendest Du? Die neuen Versionen sollten eigentlich das meiste Problemlos installieren (außer man ist auf Windows unterwegs, wo viele Abhängigkeiten wie Compiler etc. fehlen können).
Was ist der große Unterschied zwischen installieren eines Non-Core-Moduls und dem Installieren (kopieren) eines eigenen Moduls? Wenn Du etwas “deployen” willst, kannst Du alle Pakete und Skripte, die Dein Skript braucht, einfach mit PAR packen.
PAR ist eine Art zip-Archiv, ähnlich dem JAR-Format von Java.
Wie immer gibt es eine mögliche Lösung in Perl. Aber Du kannst es natürlich auch weiterhin so machen wie bisher
Ich möchte nur auf ein paar Sachen aufmerksam machen.
Gruß,
Renée
Also zunächst einmal: Ich bin ein CPAN-Fan
Gehöre aber auch zu den angesprochenen Vollzeit-Programmierern und dort ist es tatsächlich so, daß man nach einiger Zeit für fast jeden Zweck das passende Modul kennt (oder zumindest davon gehört hat). Und die größte Zeitersparnis ist der direkte Kontakt zu den Modul-Autoren. Was ich schon an Bugfixes und Features auf diesem Weg bekommen habe…
Das CPAN gerade unter Windows nicht ganz einfach ist, ist nicht von der Hand zu weisen. Daran wird in der Perl-Community auch gearbeitet (Adam Kennedy setzt sich derzeit sehr stark für Windows ein). Allerdings, mit etwas “Grundwissen” läßt sich fast alles unter Windows (auch ohne eigenen C-Compiler) installieren:
http://theoryx5.uwinnipeg.ca/ppms/
Daneben gibt es für viele große Module (z. B. Gtk2) eigene PPM-Repository. Und Pure-Perl-Module lassen sich in 90% der Fälle auch mit nmake installieren. Manches läuft halt aufgrund schlechter Programmierung (keine Verwendung von File::Spec) nicht, oder die Testsuite geht nicht…
Und was DBD::SQLite angeht, das ist ein besonderes Kapitel. Die 1.13 ist “broken”, was zwar vielen bekannt ist, aber es tut sich nichts. Produktiv würde ich hier nur die 1.12 einsetzen, aber momentan tendiere ich dazu SQLite überhaupt nicht produktiv einzusetzen
Uwe
PS: Wenn mir die Eigenwerbung erlaubt ist: Ich habe einen Artikel zur Installation von Perl und CPAN-Modulen unter Windows in der Vorbereitung. Da es für Einsteiger doch etwas kompliziert ist. Die Bilder sind zwar schon gemacht, aber der Text fehlt noch. Ein paar Wochen wird es wohl noch dauern…
Danke Uwe für deine äußerst interessante Antwort.
Ich hab mich in letzter Zeit öfters gefragt, ob es denn nicht möglich wäre, im CPAN die Module deutlich zu kennzeichnen mit “Ist im Core” und “Ist im Windows ActivePerl-Repository” enthalten. Und natürlich wäre es hilfreich, dass eine als “broken” bekannte Version auch so gekennzeichnet oder gar vom CPAN entfernt wird. (Wobei ich seit der erfolgreichen Installation von DBD::SQLite 1.13 keine Probleme damit habe. Hab hier auf dem MacBook eine 1,5 GB große Tabelle mit 40 Mio. Datensätzen, läuft einwandfrei.)
Die ganzen CPAN-Probleme stören ja letztendlich das Deployment. Denn mit Perl muss man Entwicklungs- und Produktivrechner weitgehend synchron halten. Mit Java hingegen ist das meist deutlich einfacher. :-/
Dafür gibt es http://search.cpan.org/perldoc?Module::CoreList - eine Kennzeichnung auf search.cpan.org wäre eine gute Idee.
Die PPM von ActiveState sind ja meist sehr alt. Hier will ActiveState Geld dran verdienen
Zu SQLite: mit “broken” war ich vielleicht etwas hart - die Version ist “buggy”. Viele O/R-Mapper müssen explizit Bugs in der 1.13 “ausbügeln”. Ich erinnere mich mit Grauen an eine RT-Installation mit SQLite - die wurde immer langsamer (bei kleiner DB-Größe von 30 - 40 MB). Als ich die DB gewechselt habe, läuft das Ding wieder schnell. Das kann aber z. T. an RT liegen (schlecht gewählte Indizies oder Datenstruktur/Queries - habe ich nicht weiter untersucht).
CPAN ist halt Anarchie, deshalb gibt es fehlerhafte oder verwaiste Versionen und auch ganz großen Mist. Es kann eben jeder sein Zeug hochladen
Zum Deployment: Lege Dir doch die auf dem Testrechner installierten Versionen mit ins SVN. Und dann installierst Du nur diese Versionen (geht auch mit CPAN.pm - einfach kompletten Pfad/Distname angeben). Mit Java kenne ich mich zu wenig aus, um dies vergleichen zu können. Aber Tomcat ist auch nicht ohne…
Mit einer guten Test-Suite kannst Du Dir sogar Unterschiede in den Versionen erlauben (sowohl in den CPAN-Modulen als auch in Perl selbst).
Bevor hier ein falsches negatives Licht auf Perl geworfen wird: Jede Sprache hat Ihre Probleme. Im großen und ganzen ist CPAN eine Supersache. Klar, daß man sich in ein neues Modul erst einarbeiten muß. Und bei großen Modulen wie Catalyst, FormBuilder oder Template-Toolkit dauert das eben auch mal etwas länger
Uwe
Dass die PPMs von ActiveState meist “veraltet” sind, hat nichts damit zu tun, dass sie mit Perl ein Teil ihres Geldes verdienen. Es hat damit zu tun, dass sie abwärtskompatibel bleiben wollen.
ActiveState tut sehr viel für die aktive Perl-Entwicklung.
Dass es keinerlei Kontrolle bei CPAN gibt, hat Vor- und Nachteile. Es hat den Vorteil, dass man dort alles findet und es hat den Nachteil, dass man dort alles findet
Wer kann sich denn anmaßen, zu kontrollieren, was auf CPAN darf und was nicht?
Was ich mir wünschen würde, wäre eine Datei, die mit CPAN.pm ausgeliefert werden würde, in der Sachen wie PASSes und FAILs der CPAN-Tester aufgeführt würden - und am besten noch die Kwalitee.
Dann hätte man auch mehr Kontrolle darüber, ob eine Version “broken” ist oder nicht.
@Stefan: Was ist am Deployment bei Java so gut? Wie wird es gemacht?
Vielleicht gibt es so etwas für Perl schon oder man könnte es entwickeln.
Ich denke, dass Perl und Windows immer besser zusammenpassen werden. Zum Einen durch die Bestrebungen, die auch von Uwe angesprochen wurden und bei http://win32.perl.org verfolgt werden können und zum anderen wird das dadurch unterstützt, dass die Zahl der Windows-User unter den Perl-Programmierern stetig steigt.
Ich kann mich noch an meinen ersten Perl-Workshop 2004 erinnern. Da war ich mit meinem Windows-Laptop eine echte Rarität und in diesem Jahr war der Anteil echt hoch. Und das Ergebnis der Umfrage von Yves Orton ist auch ganz interessant: http://www.nntp.perl.org/group/perl.perl5.porters/2007/02/msg121386.html
@Uwe: Gerade die Installation von Modulen mit extrem vielen Abhängigkeiten ist manchmal echt bescheiden. Vor allem wenn zirkuläre Abhängigkeiten drin sind. Dann muss man schauen, dass man irgendwo die Kette unterbricht und ein bestimmtes Modul vor dem eigentlichen Modul installiert!
Ein Problem sind die verteilten Repositories. Man kann leider nicht alle kennen, auch wenn auf http://win32.perl.org eine ziemlich große Liste ist.
Damit nur kein falscher Eindruck entsteht: Das CPAN ist ne feine Sache und die Dinge, die da drin zu finden sind, sind oftmals allererste Sahne. Derzeit setzen wir z.B. für ein Neomo-Projekt intensiv und sehr erfolgreich Win32::IEAutomation ein.
Es ist halt nur sehr ärgerlich, wenn sich eigentlich simple Sachen wie die SQLite-Bindings nicht installieren lassen. Bei Java ist halt sozusagen die Core-Library von Haus aus deutlich umfangreicher, damit fallen viele Dinge simpler aus. Wobei ihr natürlich recht habt, dass es da - siehe Tomcat - auch oft recht grässliche Installationsorgien gibt.
Mir ist bewusst, dass meine CPAN-Beschwerden viel mit meiner speziellen Situation zu tun haben: Ich programmiere nicht Vollzeit und habe dann meist Prototypen zu erstellen. Und gerade beim Prototyping ist es ärgerlich, wenn man mithilfe des CPAN ein cooles Programm geschrieben hat, das auf den Rechnern (Linux-Rechern wohlgemerkt) unserer Mitarbeiter nicht läuft, weil sich das fragliche Modul aus mysteriösen Gründen nicht installieren lässt.
Aber ich glaube, dass meine Situation durchaus ähnlich ist mit der Situation von Leuten, die mal kurz zu Perl reinschnuppern möchten, sich vom oberflächlichen Aussehen des Codes zwar noch nicht abschrecken ließen, aber von den CPAN-Ärgernissen zu Ruby oder Python oder gar Java getrieben werden.
[…] CPAN - das ist auch ein Problem von Perl: die Leute müssen SO VIELE Module installieren, um Bugzilla zu nutzen CPAN halte ich in der Tat für ein Problem. Den Kampf mit der Installation diverser Module hab ich schon beschrieben. Erschwerend kommt hinzu, dass in Perl viele Corefeatures Teil von CPAN-Modulen sind. Das macht das Deployment von Perl-Anwendungen nicht immer einfacher. […]
[…] Microsoft und Perl, das ist bislang nicht die große Liebe. Zwar gibt es mit ActivePerl eine gut funktionierende Perl-Version für Windows; auch die von ActiveState mitgelieferten CPAN-Module lassen sich problemlos installieren. Doch wehe, der Windows-Perl-Entwickler versucht, ein anderes CPAN-Modul zu laden. Dann trifft ihn der CPAN-Wahnsinn. […]
[…] habe hier schon ein paar Mal das Sakrileg begangen und über Perls CPAN-System gelästert. Denn viel zu oft klappt die Installation eines CPAN-Moduls nicht; nicht nur unter Windows, aber da […]
Nach vielen Stunden mit CPAN auf Windows - ohne Erfolg - bin ich endlich fündig geworden:
http://strawberryperl.com/
Da funktioniert gzip (ohne broken pipe), nmake! etc.