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.

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.

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

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. :-/

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…

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