| NOME |
perlnewmod - preparare un nuovo modulo per distribuirlo
Questo documento vi dà alcuni suggerimenti su come procedere per scrivere moduli Perl, prepararli per distribuirli e renderli disponibili attraverso CPAN.
Una delle cose che rendono il Perl davvero potente è il fatto che gli hacker del Perl tendono a voler condividere le soluzioni ai problemi che hanno già affrontato, cosicché voi non dobbiate combatterci di nuovo.
Il modo principale per realizzare questa condivisione è mediante un'astrazione della soluzione in un modulo Perl. Se non sapete cos'è una di queste cose, il resto di questo documento non vi sarà di molta utilità. Vi manca inoltre la conoscenza di una cospicua quantità di codice utile; considerate l'idea di dare un'occhiata a the perlmod manpage, the perlmodlib manpage e the perlmodinstall manpage prima di ritornare qua.
Quando avete trovato che non c'è un modulo disponibile per quello che state cercando di fare e voi stessi siete stati costretti a scrivere il codice, prendete in considerazione di fare un pacchetto della soluzione, farlo diventare un modulo e caricarlo su CPAN in maniera che altri possano beneficiarne.
In questa sede andremo a concentrarci principalmente sui moduli scritti unicamente in Perl, piuttosto che moduli XS. I moduli XS servono ad uno scopo piuttosto differente e potreste prendere in considerazione differenti aspetti prima di distribuirli: la popolarità delle librerie che state unendo tra loro, la portabilità su altri sistemi operativi e così via. Ad ogni modo, le note sulla preparazione del lato Perl del modulo, il renderlo un pacchetto e distribuirlo si applicano ugualmente bene sia ad un modulo XS che ad uno di solo Perl.
Dovreste mettere in un modulo tutto quel codice che pensate sarà utile agli altri. Tutto quello che è verosimile riempia un buco nella liberia della comunità e che qualcun altro possa introdurre direttamente nei propri programmi. Qualsiasi parte del vostro codice che potete isolare, estrarre e inserire in qualcos'altro, è un candidato adatto.
Facciamo un esempio. Supponiamo di leggere dei dati da un formato di dati locale ad un hash di hash in Perl, trasformarlo in un albero, traversare l'albero e poi riversare ogni nodo in un Server Transmogrifero della Acme.
Ora, un bel numero di persone hanno il Transmogrifero della Acme e e voi avete bisogno di scrivere da zero qualcosa che parli il protocollo - vorrete quasi certamente farne un modulo. Il livello al quale lo imposterete è lasciato a voi: potreste volere dei moduli a livello di protocollo analoghi a Net::SMTP che poi comunicano a moduli di alto livello analoghi a Mail::Send. La scelta è vostra ma voi volete assolutamente tirare fuori un modulo per il protocollo di quel server.
Nessun altro sul pianeta comunicherà utilizzando il vostro formato locale, dunque questo aspetto possiamo ignorarlo. Ma che dire di tutto quel che c'è in mezzo? Costruire strutture ad albero a partire da variabili Perl e poi traversarle, è un problemino carino e generale, e se nessuno sta già scrivendo un modulo che fa questo, potreste voler modularizzare anche questo codice.
Così, se tutto va bene, ora avete alcune idee su cosa sia buono da modularizzare. Ora andiamo a vedere come si fa.
Prima ancora di partire a grattar via il codice, ci sono alcune cose che dovremmo fare in anticipo.
WWW::Mechanize
ed i moduli Email::*, infine, forniscono buoni esempi di codice orientato agli
oggetti.
Questi dovrebbero darvi una idea generale su come i moduli vanno impostati e scritti.
comp.lang.perl.modules, oppure come ultima spiaggia chiedete nella lista di
discussione sui moduli su modules@perl.org.
Ricordatevi che questa è una lista chiusa con un tempo di evasione
molto lungo - preparatevi ad aspettare un bel po' per una risposta.
Quando avete vagliato il nome e siete sicuri che il modulo sia voluto e non disponibile al momento, è tempo di iniziare a scrivere codice.
module-starter --module=Pippo::Pluto \
--author="Tuo Nome" --email=tuonome@cpan.org
Se non volete installare da CPAN il pacchetto Module::Starter, h2xs è uno strumento più vecchio, inteso in origine per lo sviluppo di moduli XS, che si trova come pacchetto nella distribuzione Perl.
Una tipica invocazione di h2xs per un modulo di solo Perl è:
h2xs -AX --skip-exporter --use-new-tests -n Pippo::Pluto
Il -A omette il codice Autoloader, -X omette gli elementi XS,
--skip-exporter omette il codice Exporter, --use-new-tests allestisce
un ambiente moderno per i test e -n specifica il nome del modulo.
warn "Non e` stato dato il nome dell'host";
l'utente vedrà qualcosa come questo:
Non e` stato dato il nome dell'host at /usr/local/lib/perl5/site_perl/5.6.0/Net/Acme.pm
line 123.
che sembra come se il vostro modulo stia facendo qualcosa di sbagliato. Invece, volete dare la colpa all'utente, dicendo questo:
Non e` stato dato il nome dell'host at cattivo_codice, line 10.
Questo si fa usando Carp e sostituendo i vostri warn con dei
carp. Se avete la necessità di usare die, dichiarate invece croak.
Ad ogni modo, mantenete warn e die al loro posto per i vostri controlli interni -
dove il vostro modulo è davvero colpevole.
use Net::Acme qw(&gingillo) importerebbe la subroutine
gingillo.
La variabile di package @EXPORT determinerà quali simboli saranno
esportati quando il chiamante dichiara semplicemente use Net::Acme -
difficilmente vorrete metterci qualcosa. @EXPORT_OK, dall'altro lato,
specifica quali simboli siete disposti ad esportare. Se volete esportare
parecchi simboli, usate gli %EXPORT_TAGS e definite un insieme
di esportazione standard - date un'occhiate a the Exporter manpage per maggiori
dettagli.
module-starter oppure h2xs vi forniranno
uno schema da riempire; se non siete sicuri sul formato, date un'occhiata
a the perlpod manpage per un'introduzione. Si è soliti fornire nel codice una buona
sinossi di come funziona il vostro modulo, una descrizione, e poi delle
note sulla sintassi e funzionamento delle singole subroutine o metodi.
Utilizzate i commenti Perl per le note agli sviluppatori e POD per le
note agli utenti finali.
module-starter e h2xs forniranno una
infrastruttura per i test che potete estendere - dovrete fare qualcosa
di più del semplice controllo che il vostro modulo compili.
Test::Simple e Test::More sono dei buoni
punti da cui partire quando si sta scrivendo un insieme di programmi
di test.
http://pause.perl.org/, selezionate
``Request PAUSE Account'' [``Richiesta di un Account PAUSE'', NdT] ed
aspettate che la vostra richiesta venga approvata dagli amministratori
di PAUSE.
perl Makefile.PL; make test; make distmodule-starter oppure h2xs hanno fatto tutto il
lavoro per voi. Essi producono il Makefile.PL standard che potete
vedere quando scaricate e installate dei moduli e questo produce un
Makefile con un target di dist.
Una volta che vi siete assicurati che il vostro modulo abbia passato
i propri test - è sempre una buona cosa assicurarsene - potete eseguire
un make dist e il Makefile, se tutto va bene, produrrà una simpatica
tarball [il file creato con l'utility tar, NdT] del vostro modulo, pronto
per effettuarne l'upload.
comp.lang.perl.announce.
Simon Cozens, simon@cpan.org
Aggiornato da Kirrily ``Skud'' Robert, skud@cpan.org
the perlmod manpage, the perlmodlib manpage, the perlmodinstall manpage, h2xs, the strict manpage, the Carp manpage, the Exporter manpage, the perlpod manpage, the Test::Simple manpage, the Test::More manpage the ExtUtils::MakeMaker manpage, the Module::Build manpage, the Module::Starter manpage http://www.cpan.org/ , il tutorial di Ken Williams su come costruire il proprio modulo su http://mathforum.org/~ken/perl_modules.html
La versione su cui si basa questa traduzione è ottenibile con:
perl -MPOD2::IT -e print_pod perlnewmod
Per maggiori informazioni sul progetto di traduzione in italiano si veda http://pod2it.sourceforge.net/ .
Traduzione a cura di dree.
Revisione a cura di Flavio Poletti.
| NOME |