Neues in der Kategorie Module/CPAN

Tie::DNS ist ein praktisches Modul, um sehr einfach und komfortabel DNS-Abfragen zu tätigen: Man braucht nur noch auf einen Hash zugreifen und hat schon die passenden Daten parat.

   tie my %test, "Tie::DNS";
   say "Test.de: $test{'test.de'}";
   say "Perl-Blog: $test{'www.perl-blog.de'}"; 

Leider ist es bisher nicht möglich, einen anderen Nameserver als den Standard-Nameserver vom System anzugeben oder andere Parameter vom Net::DNS::Resolver zu ändern. Ein kleiner Patch – auch an Maintainer Dana M. Diederich geschickt – behebt das Problem. Dann kann man auch Nameserver angeben:

   tie my %test, "Tie::DNS", { resolver_args => { nameservers => ['127.0.0.1'] } };;
say "Test Lokal: $test{'test.local'}";
say "intern: $test{'intern.intern'}";


tie-dns-patch-resolver_args.diff

 

Wie kann ich CPAN-Module wieder entfernen bzw. deinstallieren? Auf den ersten Blick ist das einfach: einfach die betreffenden .pm-Dateien löschen, schon ist das Modul weg.

Aber was ist mit eventuellen weiteren Dateien oder Distributionen, die aus vielen Modulen bestehen? Oder mit Modulen mit in mehreren Verzeichnissen verstreuten Dateien?

Dafür bietet CPANPLUS bzw. dessen Shell cpanp das Uninstall-Kommando. Dies entfernt alle installierten Komponenten eines Modules. Dazu bedient es sich der .packlist-Dateien, die in <perllib>/<architektur>/auto/<modulname> abgelegt werden und eine Liste aller installierten Komponenten enthalten.

CPANPLUS wird ab Perl 5.10 mitgeliefert, in älteren Versionen lässt es sich ganz normal via CPAN nachinstallieren.

Laut einem Bericht von heise online bzw. der Washington Post wurde ein sehr Spammer-freundlicher  Provider gestern vom Netz getrennt – und prompt ging das Spam-Aufkommen weltweit nach unten.

Das kann ich auch bestätigen. Mein SpamAssassin hat auch nur noch die Hälfte zu tun. Gestern hat er nur noch 1597 Spams ab Spam-Level 8 und 44 Spams mit Level 5 bis 7 wegfiltern müssen. Aber leider landen immer noch zu viele nervige Spams in meiner Inbox, jeweils ca. 1% des Spam-Aufkommens.

Die Statistik der gefilterten Spams der letzten Tage:

  12. 11.: 1597 +  44
  11. 11.: 3224 + 110
  10. 11.: 3244 +  93
   9. 11.: 2633 +  75
   8. 11.: 2717 +  69
   7. 11.: 3115 +  66

 

Daher muss man diesmal nicht nur SpamAssassin und Perl danken, sondern auch den Providern, die das abgeschaltet haben.

 

Thomas Fahle hat eine schöne Einführung geschrieben, wie man mit GraphViz::Data::Grapher von Léon Brocard komplexe Datenstrukturen visualisieren kann.

Ich habe es zwar nicht ausprobiert, aber das sieht äußerst praktisch aus. Da würde ich mir ja auch eine Integration in den Debugger von EPIC, dem Perl-Plugin für Eclipse, wünschen: ein Klick oder Tastenkürzel beim Debuggen, und die Datenstruktur erscheint als Grafik ...

Letzte Woche habe ich eine Perl-Schulung bei einer Versicherung gegeben. Und da ich schon befürchtet habe, dass die Netz-Anbindung und damit auch der Zugriff aufs CPAN da eventuell schwierig wird, hatte ich vorher mit minicpan einen lokalen CPAN-Mirror erstellt.

Vor Ort war dann tatsächlich nur sehr eingeschränkter Netzzugriff (und für mich gar keiner) möglich: Zugriff nach draußen nur mittels HTTP-Proxy, der aber eine NTLM-Authentifizierung verlangt. Also ist (ohne weiteres) kein Zugriff aufs CPAN möglich.

Die Lösung ist also ein lokaler CPAN-Mirror auf dem Fileserver. Dummerweise brach das Kopieren der Dateien nach einiger Zeit ab. Und der betreffende Mitarbeiter erhielt kurz darauf per Mail eine Virus-Warnung: er habe versucht auf dem Fileserver einen Virus abzulegen und die Mail wurde gelöscht. Durch einen Anruf konnte er gerade noch verhindern, dass die Sicherheitstruppe mit dem Rollkommando vorbeikommt, wie das dort üblicherweise bei Viren-Epidemien passiert ... Ups!

Ein Virus auf dem CPAN?

Nun, der Virus ist in Mail::ClamAV enthalten, bei den Tests. Und es ist gar kein richtiger Virus, sondern nur der eicar-Test-Virus „The Anti-Virus or Anti-Malware test file“, mit dem man die Funktionsfähigkeit eines Viren-Scanners testen kann. Wie man sieht, funktioniert er bei besagter Versicherung ...

Mail::ClamAV ist also vorbildlich und testet auch, ob wirklich alles klappt. In so mancher Konstellation kann das aber zu Problemen führen.

Also: Vorsicht beim Ablegen des kompletten CPAN-Mirrors auf einem Server, der die Dateien auf Viren testet. Es könnte Probleme und Ärger mit der Sicherheitsabteilung geben. Und in Zukunft sollte Mail::ClamAV den Test-Virus doch lieber nur (leicht) verschlüsselt ablegen und ganz deutlich als Test-Virus kennzeichnen. Ich schreibe gleich mal einen Bug-Report ...

Letztens hatte ich ein paar Probleme mit dem CPAN unter der Strawberry-Perl-Installation unter Windows auf einem Laptop vom Kunden. Mit Windows zu arbeiten ist ja meistens schon Strafe genug, es scheint aber, dass diese Probleme nicht nur mit Strawberry-Perl auftreten:

Bei dem Versuch der Installation eines Modules kam die folgende Fehlermeldung:

Can't call method "value" on an undefined value at c:/strawberry/perl/lib/IO/Uncompress/RawInflate.pm line 64

Die CPAN-Shell konnte noch nicht mal die Modulliste auspacken geschweige denn irgendwas installieren. Die Lösung war dann nach langem Probieren: Die Version 2.008 von IO::Uncompress::RawInflate (in IO-Compress-Zlib) und alle Abhängigkeiten bzw. die weiterem IO::(Un)Compress::*-Module habe ich manuell auf die Version 2.011 aktualisiert und dann ging wieder alles.

Ergänzung: Unter Linux oder einem Unix-ähnlichen System mit lokalem gzip/bzip2 könnte es auch klappen, die Module zu löschen, so dass Perl ein lokales CLI gunzip/bunzip2 nimmt.

 

Zuvor hatte ich noch ein anderes Problem:

cpan> install Foo::Bar
DBD::SQLite::db prepare failed: no such table: dists(1) at dbdimp.c line 271 at C:\strawberry\perl\site\lib/CPAN/SQLite/
DBI/Search.pm line 86, <IN> line 2.
Catching error: 'DBD::SQLite::db prepare failed: no such table: dists(1) at dbdimp.c line 271 at C:\\strawberry\\perl\\s
ite\\lib/CPAN/SQLite/DBI/Search.pm line 86, <IN> line 2.
' at C:/strawberry/perl/lib/CPAN.pm line 281
        CPAN::shell() called at C:\strawberry\perl\bin/cpan.bat line 211

Da war die SQLite-Datenbank, in der das CPAN.pm optional die Metadaten ablegt (use_sqlite-Konfiguration), kaputt. Möglicherweise wird die zerschossen, wenn die CPAN-Shell an der falschen Stelle abgewürgt wird (bei mir: hatte vergessen mich ins VPN des Kunden einzuwählen, und ohne geht dessen Proxy natürlich nicht).

Die Lösung ist dann meist, die Datenbank oder gar alles im CPAN-Ordner zu löschen. Bei Strawberryperl liegt das unter C:\strawberry\cpan\, bei anständigen Betriebssystemen unter ~/.cpan/.

 

 

Kurzvorstellung und Bugfix

Ist es nicht lästig, Kommandozeilenparameter erst im Code und dann noch einmal im POD zu definieren? Getopt::Long und Pod::Usage sind zwar sehr praktisch, aber um die Dokumentation sowie Usage etc. konsistent zu halten, muss man immer an zwei Stellen ran: Code und Dokumentation.

damian-curly.jpg

Damian Conway auf der YAPC Europe 2007 in Wien – wenn er seine Module nur so gut warten würde wie er seine Vorträge hält!

 

Hier setzt das Modul Getopt::Euclid von Damian Conway an: Man definiert die Kommandozeilenschnittstelle einfach im POD und hat alles zusammen.

So weit so gut, aber nach der Nutzung von Getopt::Euclid bin ich endgültig der Ansicht: vor dem Einsatz eines Modules von Damian Conway sollte man sich dieses sowie die Bugreports dazu genau anschauen und ihm nicht blind vertrauen – insbesondere wenn er es in Perl Best Practices empfohlen hat. Dieses Buch ist zwar wirklich sehr empfehlenswert und Pflicht für jedes professionelle Entwicklerteam, Damians Module haben aber teilweise viele Bugs und werden eher schlecht gewartet.

Bug, Test und Fix

So hat auch Getopt::Euclid einige Bugs. Besonders fatal: die aktuelle Version ignoriert auf einem Unix-System das POD, wenn die Zeilenenden im Windows-Format vorliegen und umgekehrt (siehe auch den Bugreport). Das ist sehr ärgerlich.

Aber ein Bugfix bzw. Getopt::Euclid Patch (mit allen Dateien im Archiv) steht bereit ...

Um das Problem zu fixen habe ich mir das Modul angeschaut und war doch einigermaßen erstaunt: Anstatt auf einen Pod-Parser vom CPAN zurückzugreifen baut Damian Conway selbstgestrickte tief verschachtelte Reguläre Ausdrücke; anstatt das Parameterparsing einem erprobtem Modul zu überlassen strickt er es selbst. Das gleiche gilt für die Ausgabe der Hilfe. Damit verletzt er selbst die Regeln „Verwenden Sie wann immer möglich Core-Module“ sowie „Verwenden Sie CPAN-Module, wo es möglich ist“, die er in Perl Best Practices aufgestellt hat.

 

Daher habe ich – ausnahmsweise mal ganz vorbildlich – erst einen Test geschrieben, der das Problem simuliert und es dann gefixt: Der Einfachheit halber werden alle möglichen Zeilenumbrüche durch solche ersetzt, die auf dem aktuellen System üblich sind, also durch \n. (Download Patch und gepatchte Version)

HInweis: Da es kein offizieller Patch ist, habe ich die Versionsnummer nicht angepasst. Ich habe ja die Hoffnung, dass Damian ihn übernimmt.

 

Bei vielen Projekten will man die Dokumentation, die in den eigenen Modulen und Skripten (hoffentlich!) haufenweise als POD vorhanden ist, nach HTML wandeln und sich so eine lokale Dokumentation erstellen.

Mit welchen Modulen / Werkzeugen erstellt Ihr Euer HTML (oder PDF oder ...)?

Ich habe gerne Pod::ProjectDocs verwendet, da das alles auf einen Rutsch erledigt. Nur das optionale Syntax Highlighting geht derzeit nicht, da Syntax::Highlight::Universal sich nicht compilieren lässt.

Nun ist mir Pod::Classdoc mit mkprojdocs aufgefallen, das zusätzlich auch noch Javadoc-ähnliche Formatierung erlaubt. Damit lassen sich dann relativ übersichtlich alle Ein/Ausgabeparameter auflisten. Bisher habe ich das gerne mit =item-Listen gemacht, aber dann wird der POD-Quelltext schnell unübersichtlich. Hierfür Javadoc zu nutzen erscheint also eine ganz brauchbare Lösung zu sein.

Es gibt ansonsten noch dutzende POD-Parser und -Konverter im CPAN; Pod::Simple mit Pod::Simple::HTMLBatch sieht evtl. auch brauchbar aus. Aber Pod::ProjectDocs bzw. Pod::Classdoc mit mkprojdocs scheint mir das einzige zu sein, dass ohne eigene Basteleien sofort funktioniert.

Update: Pod::POM::Web habe ich ganz vergessen zu erwähnen, mit dem man die Dokumentation zu allen lokal installierten Modulen im Browser nutzen kann. Eine sehr praktische Sache, aber auch nicht immer geeignet.

 

Vor ein paar Tagen wurde eine neue Version des DBI-Treibers für PostgreSQL freigegeben: 2.1.3 ist die aktuelle DBD::Pg-Version auf dem CPAN.

Im Vergleich zur Version sind laut Changelog nur ein paar Kleinigkeiten dazu gekommen. 2.0 kam vor rund zwei Wochen und bringt einige neue Features mit:

  • Echte Unterstützung für Arrays in PostgreSQL
  • Unterstützung für asynchrone Queries
  • Anpassungen an neuere Postgres-Versionen und Unterstützung neuer Features
  • Diverse Bugfixes

Insbesondere die Unterstützung für Arrays sowie für asynchrone Queries finde ich sehr interessant.

Mit der Array-Unterstützung ist es nun möglich, beim schreibenden Queries auf ein Array-Feld einfach eine Array-Referenz zu übergeben und direkt an die Datenbank weiterzuleiten ohne dieses manuell in einen String zu wandeln. Umgekehrt erhält man auf Perl-Seite beim Lesen eine Array-Referenz anstatt eines flachen Strings.

Mit asynchronen Queries ist es möglich, weiter Perl-Code auszuführen während ein SQL-Query läuft. Damit kann dann nicht nur parallel weitergerechnet werden, der Query kann zur Laufzeit bei Bedarf auch abgebrochen werden. Das ist natürlich insbesondere bei mehreren Prozessoren oder Kernen interessant: Während der eine Kern die nächsten Daten aus der Datenbank holt, kann der andere die letzten Daten aufbereiten. In der DBD-Pg-Dokumentation sind ein paar praktische Beispiele enthalten.

Wer bisher noch kein PostgreSQL einsetzt sollte es sich mal anschauen. Mit der aktuellen Version 8.3 kamen nochmals sehr viele Features hinzu, PostgreSQL ist standardkonform, sicher, kann weit mehr als das häufig eingesetzte MySQL und ist sehr schnell. Bei einem (einfachen) Performance-Test (siehe Seite 19ff) vor rund einem Jahr war es selbst bei sehr einfachen Queries rund 50% schneller als MySQL. Bei Gelegenheit werde ich mal messen, wie sich DBD::Pg 2 gegenüber 1.49 verhält …

Gerade bei den Perl-Nachrichten gelesen:

Best Practical hat ein neues Packaging Tool für Perl veröffentlicht: Shipwright.

Mit diesem Tool können Anwendungen mit riesigen Abhängigkeiten schnell installiert werden, da sich die Installation auf eine Kommandozeile reduziert.

Dabei ist es auch egal, ob die Abhängigkeiten CPAN-Module, sonstige Libraries oder Module in einem SVN/SVK-Repository sind.

 

Mir scheint, dass Best Practical Shipwright zum leichteren Verteilen ihres Web-Entwicklungs-Frameworks Jifty entwickelt haben, dass ja auch haufenweise Abhängigkeiten hat. Wenn es damit relativ einfach möglich wird solche großen Projekte sauber und zuverlässig zu verteilen, so dass auch Nicht-Perl-Freaks das schnell hinkriegen, dann ist das sicherlich sehr gut.

Leider ist die Dokumentation noch etwas mager, auch das Shipwright-Tutorial ist sehr knapp gehalten. Aber, und darum landet es in der Kategorie „Notizen“, ich werde mir das bei Gelegenheit mal näher anschauen.

Und gleich noch ein Update:
Best Practical berichtet von einem kleinen Test, demnach kann man umfangreiche Installationen mit einem Kommandozeilenaufruf erledigen. Die Installation erfolgt in ein temporäres Verzeichnis und die erstellte Binärdistribution lässt sich in einen beliebigen Ordner verschieben. (via Thomas Fahle)

Aktuelle Kommentare

  • Niels Dettenbach: ...schade eigentlich, das es PyPerl nicht mehr wirklich gibt. Zwar weiter lesen
  • Alvar Freude: Kannte ich noch nicht, danke für den Hinweis; allerdings ist weiter lesen
  • Ben Sieverts: Ich vermisse noch folgendes Buch auf der List: Effective Perl weiter lesen
  • Alex: Ich schlage einfach mal ganz unverschämt bei diesem Beitrag die weiter lesen
  • Marcel: Oke, danke für den Tipp. Schade natürlich. Wird euer Buch weiter lesen
  • Alvar: Nein, leider ist das noch nicht fertig. :-( Es gibt weiter lesen
  • Marcel : Hallo! gibt es dein Buch zu Perl6 schon? Wo kann weiter lesen
  • air max 2009: Nimm ein Paradigma deiner Wahl (z.b. MVC) und lerne Applikationscode weiter lesen
  • vTasker: Was ist das denn für ein MIST? Der Artikel ist weiter lesen
  • Virenschutz-Test: Das ist ja lustig hihi. Der Admin ist wohl nicht weiter lesen

Über dieses Archiv

Diese Seite enthält aktuelle Einträge der Kategorie Module/CPAN.

Guter Code ist die vorherige Kategorie.

Movable Type ist die nächste Kategorie.

Aktuelle Einträge finden Sie auf der Startseite, alle Einträge in den Archiven.