Warum CPAN Module installieren?
Bapf
- perl
Hallo,
ich frage mich, warum ich die CPAN Module installieren muss. Ich bekomme nur auf Umwege root Rechte und möchte den Source der Module die ich brauche eigentlich bei den Perl Programm Dateien lassen, die ich selbst geschrieben habe.
Angenommen ich schreibe selbst ein Programm in Perl, welches die gleichen Aufgabe der Module erfüllt, müsste ich dieses ja auch nicht installieren, sondern würde es neben dem Hauptprogramm mit "use meinBenoetigtesModul;" einbinden und lege die Datei "meinBenoetigtesModul.pm" mit in das Directory wo auch mein hauptprogramm.pl liegt.
Gibt es die Möglichkeit die *.pm Dateien der CPAN Downloads zu verwenden, ohne "perl Makefile.PL, make, make test, make install" ?
Es geht speziell um die Module DBD-CSV, SQL-Statement, XML2CSV und TEXT-CSV_XS. Wenn ich mir den Inhalt ansehe, deutet nichts darauf dass diese in C geschrieben wurden.
ich frage mich, warum ich die CPAN Module installieren muss. Ich bekomme nur auf Umwege root Rechte und möchte den Source der Module die ich brauche eigentlich bei den Perl Programm Dateien lassen, die ich selbst geschrieben habe.
In jeder Programmiersprache gehören Module oder Libaries zum Umfang, ohne bräuchte man um z.b. in C ein windows Programm zu schreiben Jahre dafür. Auch Dateioperationen sind auf Interrupt Ebene nicht unbedingt ein Spaß. Und Perl hält es halt nicht für sinnvoll zig Tausende Funktionen im Kern einzubinden wie PHP.
Deshalb ist das CPAN und deren Module eine der herrausragenden Pluspunkte von Perl. Die Frage müßte also umgekehrt lauten, warum sollte man keine Module verwenden?
Gibt es die Möglichkeit die *.pm Dateien der CPAN Downloads zu verwenden, ohne "perl Makefile.PL, make, make test, make install" ?
Nur bei puren Perl Modulen.
Es geht speziell um die Module DBD-CSV, SQL-Statement, XML2CSV und TEXT-CSV_XS. Wenn ich mir den Inhalt ansehe, deutet nichts darauf dass diese in C geschrieben wurden.
doch: require DynaLoader;
Struppi.
Hallo,
Gibt es die Möglichkeit die *.pm Dateien der CPAN Downloads zu verwenden, ohne "perl Makefile.PL, make, make test, make install" ?
Ja, aber nicht alle!
Funktionierendes Beispiel:
Script liegt in /cgi-bin/myscript.pl
Modul liegt in /cgi-bin/Config/IniFiles.pm
wird eingebunden im Script mit
use Config::IniFiles;
Mit Modulen, die einen C-Compiler erfordern, klappt das so nicht, weil neben dem Kopiervorgang in das ensprechende lib-Verzeichnis auch noch binaries erzeugt werden, wie Shared-Objects-Libraries (.so).
Anders Module für Win32-Perl, die werden zweckmäßig mit ppm installiert, etwaige .dll oder andere bins sind da schon fix und fertig mit dabei.
Schau Dir einfach die tar.gz an, lies die README und schaue nach Dateien, die nach c "riechen".
Viele Grüße,
Hotte
Gibt es die Möglichkeit die *.pm Dateien der CPAN Downloads zu verwenden, ohne "perl Makefile.PL, make, make test, make install" ?
Ja, kannst Du, allerdings mit teilweise unerwarteten Ergebnissen. So enthält Makefile.pl u.a. Angaben dazu, welche weiteren Bibliotheken für das zu installierende Modul erforderlich sind.
Es geht speziell um die Module DBD-CSV, SQL-Statement, XML2CSV und TEXT-CSV_XS. Wenn ich mir den Inhalt ansehe, deutet nichts darauf dass diese in C geschrieben wurden.
Schon möglich. Allerdings hast Du Verknüpfungen zwischen den Modulen (use/require), die Du entsprechend in @INC abbilden müsstest. Hast Du keine Rootrechte, bleibt Dir nur das Abbilden in cgi-bin, was zwar prinzipiell möglich ist, aber einiges an Arbeit erfordert: Du musst sämtliche Makefile.pl durchforsten, nach PREREQ_PM schauen, die dort genannten Module auf Vorhandensein in der erforderlichen Version untersuchen und sie ggf. unter Beachtung von PREREQ_PM in deren Makefile.pl "installieren" usw. usf.
Du siehst, eine Installation mit Hilfe der für die Zielplattform vorgesehenen Möglichkeiten (ppm, nmake, make usw.) ist der Königsweg. Ansonsten frage Deinen Hoster, ob er Dir die gewünschten Pakete installiert oder Dir einen vorübergehenden Root-Zugang gibt.
Siechfred
Es geht speziell um die Module DBD-CSV, SQL-Statement, XML2CSV und TEXT-CSV_XS. Wenn ich mir den Inhalt ansehe, deutet nichts darauf dass diese in C geschrieben wurden.
Schon möglich.
Nein - nicht möglich, eine der ersten Zeilen von DBD::CSV und TEXT-CSV_XS ist use DynaLoader
DynaLoader - Dynamically load C libraries into Perl code
Er wird also nicht um den von dir beschriebenen Weg herum kommen.
Struppi.
Moin Moin!
Wer sagt, dass man zum Installieren von Perl-Modulen Root-Rechte braucht?
Die FAQ sagt was anderes, siehe Punkt 5.
Sinnvollerweise richtet man sich irgendwo (notfalls im Dokumentenverzeichnis des Webservers) einen Verzeichnis-Baum für eigene Perl-Module ein, genau nach Punkt 5. Den Baum schottet man mit .htaccess oder Server-Konfiguration komplett ab (Order deny, allow; Deny from all), und schreibt in alle Perl-Scripte, die die eigenen Module brauchen, ein "use lib '/wo/auch/immer/myperl/lib';" rein, bevor die eigenen Module geladen werden. Sprich:
#!/usr/local/bin/perl -T
use strict;
use warnings;
use lib '/wo/auch/immer/myperl/lib'; # anpassen!
use Text::CSV_XS; # als Beispiel
# mach was mit Text::CSV_XS
Ein C-Compiler wird auf dem System der Beschreibung nach ja vorhanden sein.
Um Perl-Module, die C-Erweiterungen benötigen, sicher zu erkennen, reicht DynaLoader als Kriterium nicht aus, es gibt mindestens auch noch den XSLoader. Ein Blick ins TAR-Archiv von CPAN ist in aller Regel hilfreicher. Dateien mit den Extensions C, CPP, CXX, H, HPP, HXX, und vor allem XS sind extrem verdächtig.
DBD::CSV ist übrigens ein sehr schlechtes Beispiel, denn es lädt den DynaLoader zwar, aber es benutzt ihn nicht. DBD::CSV ist ein Pure Perl DBD, aber es nutzt Test::CSV_XS, das definitiv (schon im Namen) ein XS benutzt, sprich: einen C-Compiler braucht. Das könnte übrigens auch die Erklärung für das "require DynaLoader" sein: Ohne DynaLoader-Support macht das gesamte DBD::CSV keinen Sinn.
DBD::ODBC, DBD::Oracle, DBD::DB2, DBD::Pg, DBD::mysql, und fast alle anderen DBDs brauchen definitiv XS, um an die C-API der jeweiligen Datenbank anzudocken.
Alexander
Wer sagt, dass man zum Installieren von Perl-Modulen Root-Rechte braucht?
Wenn man sie in einem der in @INC hinterlegten Verzeichnisse installieren will, braucht man die schon.
Die FAQ sagt was anderes, siehe Punkt 5.
Das meinte ich mit "Abbilden", allerdings ging ich bisher davon aus, dass das nur unterhalb von cgi-bin geht. Dem ist nicht so?
Ein C-Compiler wird auf dem System der Beschreibung nach ja vorhanden sein.
Und die Möglichkeit des SSH-Zuganges, denke ich (jaja, ich weiß, Provider ohne SSH-Zugang sind kacke ;) ).
Siechfred
Vielen Dank für die Anregungen.
Wenn ich mir dass so ansehe, überrede ich den Admin doch besser die Module zu installieren. Es war trotzdem interessant, zu diesem Punkt mal etwas zu hören, denn meine Perl Literatur begründete die Installation nicht.
Kurtzer Einwand
Und die Möglichkeit des SSH-Zuganges, denke ich (jaja, ich weiß, Provider ohne SSH-Zugang sind kacke ;) ).
selbst den SSH Zugang brauchst du nicht wenn du ein CGI schreibts das in ein privates Lib-Directory Module installiert.
Kurtze Grüße
Moin Moin!
Wer sagt, dass man zum Installieren von Perl-Modulen Root-Rechte braucht?
Wenn man sie in einem der in @INC hinterlegten Verzeichnisse installieren will, braucht man die schon.
Man kann @INC auch über's Environment erweitern (PERL5LIB oder PERLLIB, siehe perlrun), das funktioniert aber nicht im Taint Mode.
Die FAQ sagt was anderes, siehe Punkt 5.
Das meinte ich mit "Abbilden", allerdings ging ich bisher davon aus, dass das nur unterhalb von cgi-bin geht. Dem ist nicht so?
Nö, wenn Du manuell die Unterverzeichnisse lib, bin, man/man1 und man/man3 in einem Verzeichnis Deiner Wahl angelegt hast und das CPAN-Modul analog der FAQ konfiguriert hast, erledigt cpan install Bla::Fasel den Rest (runterladen, Makefile erzeugen, übersetzen, Abhängigkeiten auflösen, testen, installieren) automatisch.
Ein C-Compiler wird auf dem System der Beschreibung nach ja vorhanden sein.
Und die Möglichkeit des SSH-Zuganges, denke ich (jaja, ich weiß, Provider ohne SSH-Zugang sind kacke ;) ).
CPAN bzw. den C-Compiler kann man auch per Telnet aufrufen. (Und ja, das ist fast genauso schlimm wie gar kein Shell-Zugang zum Server. Für mich wäre das ein Grund für einen Providerwechsel.)
Alexander