Difference between revisions of "Perl package guidelines (Italiano)"

From ArchWiki
Jump to: navigation, search
(Modulo)
(Traduzione in italiano.)
Line 3: Line 3:
  
 
{{i18n|Perl Package Guidelines}}
 
{{i18n|Perl Package Guidelines}}
{{translateme}}
 
{{Nota|Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese.}}
 
  
 
==Nomenclatura pacchetti==
 
==Nomenclatura pacchetti==
Line 93: Line 91:
  
 
Una soluzione potrebbe essere quella di specificare il path assoluto dell'interprete di sistema ({{Filename|/usr/bin/perl}}) quando si richiama il comando perl nel {{Filename|PKGBUILD}}.
 
Una soluzione potrebbe essere quella di specificare il path assoluto dell'interprete di sistema ({{Filename|/usr/bin/perl}}) quando si richiama il comando perl nel {{Filename|PKGBUILD}}.
 +
 +
===Moduli per l'installazione di moduli Perl===
 +
Uno dei maggiori vantaggi del Perl, è la grande varietà di moduli/dist packages installabili tramite CPAN. Tra gli altri, esistono moduli che si occupano dell'installazione di... moduli!
 +
 +
Ne esistono di diversi tipi, ma generalmente il procedimento è sempre lo stesso e si basa sull'inserimento di un piccolo build script nel pacchetto contenente il modulo perl: avviando questo script, il processo di compilazione e installazione ha inizio.
 +
 +
Di seguito, un elenco dei moduli più comuni:
 +
 +
====ExtUtils::MakeMaker====
 +
 +
;Build script: {{Filename||MakeFile.PL}}
 +
;CPAN Link: http://search.cpan.org/dist/ExtUtils-MakeMaker
 +
 +
Il primo, e più vecchio è sicuramente {{Codeline|ExtUtils::MakeMaker}}. Il principale svantaggio di questo sistema, è che richiede l'utility {{Filename|make}} affinché possa compilare ed installare il tutto. Benchè questo non sia un grande problema su un sistema Linux, può diventare problematico per utenti Windows!
 +
La comunità Perl sta cercando di incoraggiare l'uso di moduli più nuovi, che non hanno questo problema.
 +
 +
====Module::Build====
 +
 +
;Build Script: {{Filename|Build.PL}}
 +
;CPAN Link: http://search.cpan.org/dist/Module-Build
 +
 +
Il vantaggio principale derivante dall'uso di questo modulo, è che usa solamente perl e perciò non richiede l'utility {{Filename|make}} per funzionare. Un tempo, la sua installazione era abbastanza difficoltosa, poichè non era possibile eseguire il build script senza averlo prima installato.
 +
Ad oggi, ciò non rappresenta più un problema, poichè {{Codeline|Module::Build}} fa parte dei core modules.
 +
 +
====Module::Install====
 +
;Build Script: {{Filename|Makefile.PL}}
 +
;CPAN Link: http://search.cpan.org/dist/Module-Install
 +
 +
Di recente introduzione, {{Codeline|Module::Install}} richiede che {{Filename|make}} sia installato per funzionare. È stato scritto per essere un sostituto naturale di {{Codeline|ExtUtils::MakeMaker}}, oltre che per compensare alcune delle sue mancanze.
 +
 +
Una caratteristica molto interessante di questo modulo, è che ne viene fornita una copia all'interno del dist package, cosicchè, a differenza dei moduli sopra menzionati, non è necessario installarlo nel sistema.
 +
 +
Un'altra caratteristica di rilievo è l'auto-install. ''Anche se l'uso di questa feature non è raccomandato, questa viene usata molto spesso''. Quando l'autore del modulo ne abilita l'uso, {{Codeline|Module::Install}} procederà alla ricerca e all'installazione di tutti i moduli richiesti che non siano presenti al momento dell'esecuzione di {{Filename|Makefile.PL}}. Benchè questa funzione venga disabilitata quando {{Codeline|Module::Install}} viene eseguito da {{Codeline|CPAN}} o {{Codeline|CPANPLUS}}, ciò non accade se viene utilizzato all'interno di un '''PKGBUILD'''! Si veda [[#PERL_AUTOINSTALL|PERL_AUTOINSTALL]] per risolvere il problema.
 +
 +
===Variabili d'ambiente===
 +
Alcune variabili di sistema, possono influenzare il modo in cui i moduli sono compilati o installati, e potrebbero causare problemi inaspettati se usate in modo scorretto, specialmente all'interno di un {{Filename|PKGBUILD}}.
 +
 +
====PERL_MM_USE_DEFAULT====
 +
Quando questa variabile ha valore "true", i sistemi di installazione dei moduli descritti sopra, risponderanno ad eventuali domande con una risposta affermativa.
 +
 +
====PERL_AUTOINSTALL====
 +
È possibile passare degli argomenti a linea di comando aggiuntivi a {{Codeline|Module::Install}} attraverso questa variabile. Per disattivare l'auto-install (''altamente consigliato''), si assegni il valore {{Codeline|--skipdeps}} a questa variabile.
 +
 +
export PERL_AUTOINSTALL="--skipdeps"
 +
 +
====PERL_MM_OPT====
 +
Questa variabile consente, similmente a PERL_AUTOINSTALL, di passare degli argomenti al sistema di build. Per esempio, è possibile installare i moduli nella propria home directory usando:
 +
 +
export PERL_MM_OPT=INSTALLBASE=~/perl5
 +
 +
====PERL_MB_OPT====
 +
Uguale a PERL_MM_OPT, questa variabile è riservata a {{Codeline|Module::Build}}. Come sopra, per installare i moduli nella propria home directory:
 +
 +
export PERL_MB_OPT=--install_base=~/perl5
 +
 +
====MODULEBUILDRC====
 +
 +
{{Codeline|Module::Build}} permette di scavalcare gli argomenti a riga di comando con un file di configurazione. Di default, questo è {{Filename|~/.modulebuildrc}}. È possibile definire un file di configurazione personalizzato inserendone il percorso in {{Codeline|MODULEBUILDRC}}.
 +
 +
===Esempio rinforzato===
 +
Usando le nozioni appena acquisite, è possibile creare un PKGBUILD che resisterà a qualunque tentativo di sabotaggio da parte delle variabili d'ambiente:
 +
 +
<pre>
 +
# Contributor: Your Name <youremail@domain.com>
 +
pkgname=perl-foo-bar
 +
pkgver=VERSION
 +
pkgrel=1
 +
pkgdesc='This is the awesome Foo::Bar module!'
 +
arch=('any')
 +
url='http://search.cpan.org/dist/Foo-Bar'
 +
license=('GPL' 'PerlArtistic')
 +
depends=('perl>=5.10.0')
 +
makedepends=()
 +
provides=()
 +
conflicts=()
 +
replaces=()
 +
backup=()
 +
options=(!emptydirs)
 +
install=
 +
source=("http://search.cpan.org/CPAN/authors/id/***/***-$pkgver.tar.gz")
 +
md5sums=()
 +
 +
build() {
 +
  cd "$srcdir/***-$pkgver"
 +
 
 +
  # Setting these env variables overwrites any command-line-options we don't want...
 +
  export PERL_MM_USE_DEFAULT=1 PERL_AUTOINSTALL=--skipdeps \
 +
    PERL_MM_OPT="INSTALLDIRS=vendor DESTDIR='$pkgdir'" \
 +
    PERL_MB_OPT="--installdirs vendor --destdir '$pkgdir'" \
 +
    MODULEBUILDRC=/dev/null
 +
 +
  # If using Makefile.PL
 +
  { /usr/bin/perl Makefile.PL &&
 +
    make &&
 +
    make test &&
 +
    make install; } || return 1
 +
 +
  # If using Build.PL
 +
  { /usr/bin/perl Build.PL &&
 +
    ./Build &&
 +
    ./Build test &&
 +
    ./Build install; } || return 1
 +
 +
  # remove perllocal.pod and .packlist
 +
  find "$pkgdir" -name .packlist -o -name perllocal.pod -delete
 +
</pre>

Revision as of 16:06, 23 March 2011


This template has only maintenance purposes. For linking to local translations please use interlanguage links, see Help:i18n#Interlanguage links.


Local languages: Català – Dansk – English – Español – Esperanto – Hrvatski – Indonesia – Italiano – Lietuviškai – Magyar – Nederlands – Norsk Bokmål – Polski – Português – Slovenský – Česky – Ελληνικά – Български – Русский – Српски – Українська – עברית – العربية – ไทย – 日本語 – 正體中文 – 简体中文 – 한국어


External languages (all articles in these languages should be moved to the external wiki): Deutsch – Français – Română – Suomi – Svenska – Tiếng Việt – Türkçe – فارسی

Nomenclatura pacchetti

Per quanto riguarda i moduli, il nome del pacchetto dovrebbe iniziare con perl- e il resto del nome dovrebbe essere ricavato dal nome del modulo scritto in minuscolo, sostituendo i due punti con dei trattini. Per esempio, il nome pacchetto corrispondente al modulo HTML::Parser sarà perl-html-parser. Le applicazioni in Perl, dovrebbero mantenere il loro nome, avendo però cura di scriverlo in minuscolo.

Posizione dei files

I moduli Perl dovrebbero installare i propri files in Template:Filename (questo comportamento si può ottenere impostando la variabile Template:Codeline, come mostrato sotto). Nessun file dovrebbe essere inserito in Template:Filename, poichè quella directory è riservata ai pacchetti Perl non installati tramite il package manager. I files Template:Filename e Template:Filename dovrebbero essere presenti. Le operazioni sopra elencate vengono eseguite nel PKGBUILD d'esempio mostrato sotto.

Esempio

Un PKGBUILD d'esempio può essere trovato in Template:Filename, file fornito dal pacchetto Template:Package Official. Viene anche riportato sotto (senza i commenti):

 # Contributor: Your Name <youremail@domain.com>
 pkgname=perl-foo-bar
 pkgver=VERSION
 pkgrel=1
 pkgdesc=""
 arch=()
 url=""
 license=('GPL' 'PerlArtistic')
 depends=('perl>=5.10.0')
 makedepends=()
 provides=()
 conflicts=()
 replaces=()
 backup=()
 options=(!emptydirs)
 install=
 source=(http://search.cpan.org/CPAN/authors/id/***/***-$pkgver.tar.gz)
 md5sums=()

 build() {
  cd "$srcdir/***-$pkgver"

  # install module in vendor directories.
  PERL_MM_USE_DEFAULT=1 perl Makefile.PL INSTALLDIRS=vendor || return 1
  make || return 1
  make install DESTDIR="$pkgdir/" || return 1

  ## for packages with Build.PL, do this instead:
  # perl Build.PL installdirs=vendor destdir="$pkgdir/"
  # perl Build
  # perl Build install

  # remove perllocal.pod and .packlist
  find "$pkgdir" -name perllocal.pod -delete
  find "$pkgdir" -name .packlist -delete
 }

 # vim:set ts=2 sw=2 et:

Nella maggior parte dei casi, è consigliato inserire any nell'array Template:Codeline, poichè molti pacchetti Perl sono indipendenti dall'architettura del sistema.

Automatizzazione

Poichè Perl si basa su CPAN, esistono alcuni script che eseguono quanto scritto sopra automaticamente, risparmiandovi dallo scrivere i PKGBUILD a mano.

Il metodo più consono allo stile Perl, è quello di usare il plugin Template:Codeline, che consente di generare automaticamente pacchetti per pacman. Il plugin è installabile da qui: Template:Package AUR

Esiste inoltre uno script, chiamato Template:Package Official, che è in grado di generare ricosivamente dei PKGBUILD per un dato modulo.

Vale la pena segnalare che Bauerbill supporta la generazione di PKGBUILD in modo simile a quanto fatto da Template:Codeline, così come è in grado di aggiornare tutti i moduli CPAN direttamente da CPAN stesso attraverso un'interfaccia a pacman. Assicurarsi di leggere la pagina di manuale di Bauerbill per le istruzioni d'uso.


Argomenti avanzati

Una volta che si è acquisita dimestichezza con la creazione di pacchetti perl, è possibile leggere la sezione sottostante, che potrebbe offrire parecchi spunti interessanti. Le informazioni sotto riportate potrebbero inoltre essere utili per risolvere i problemi di pacchettizzazione.

Glossario

Si dovrebbe aver già acquisito familiarità con i seguenti termini:

Modulo

In Perl, moduli sono dichiarati con la parola chiave Template:Codeline. Essi sono contenuti all'interno di un file con estensione Template:Filename, che può a sua volta ospitare diversi moduli al suo interno. I namespace dei moduli sono separati da Template:Codeline, (due doppi punti), ad esempio: Template:Codeline. Quando si carica un modulo, i due doppi punti sono sostituiti con uno slash. Per esempio, il modulo Template:Codeline caricherà il file Template:Filename.

Core Module

I Core Modules sono quelli inclusi in un'installazione di Perl, ed alcuni di essi sono disponibili solamente con Perl stesso. Altri moduli possono invece essere scaricati tramite CPAN.

Dist Packages

Sono l'equivalente Perl di un pacchetto di Archlinux. I dist packages sono archivi Template:Filename pieni di files con estensione .pm, tests, documentazione, e tutto il necessario per i moduli ivi contenuti.

Installazione di Perl locale

Il fatto che i programmatori perl potrebbero voler installare diverse versioni di perl potrebbe rappresentare un problema, benchè ciò sia utile per verificare la retrocompatibilità dei programmi. Compilare una propria versione di perl potrebbe garantire inoltre benefici prestazionali. Inoltre, poichè spesso il perl di sistema non è all'ultima versione disponibile, l'utente potrebbe decidere di voler provare una versione più recente.

Se l'utente ha l'eseguibile perl nel proprio Template:Codeline, esso verrà eseguito quando si scrive il comando "perl" nella shell. Inoltre, questo verrà eseguito anche all'interno del Template:Filename, cosa che potrebbe causare problemi di difficile individuazione.

Il problema principale risiede nei moduli XS, che fungono da bridge tra Perl e C, usando le API proprie del Perl. Poichè queste ultime possono cambiare in modo significativo tra due versioni di Perl, se l'utente compila dei moduli XS con la propria versione dell'interprete, questi saranno incompatibili con il Perl di sistema, il quale darà luogo ad un errore di linkin quando si proverà a caricarli.

Una soluzione potrebbe essere quella di specificare il path assoluto dell'interprete di sistema (Template:Filename) quando si richiama il comando perl nel Template:Filename.

Moduli per l'installazione di moduli Perl

Uno dei maggiori vantaggi del Perl, è la grande varietà di moduli/dist packages installabili tramite CPAN. Tra gli altri, esistono moduli che si occupano dell'installazione di... moduli!

Ne esistono di diversi tipi, ma generalmente il procedimento è sempre lo stesso e si basa sull'inserimento di un piccolo build script nel pacchetto contenente il modulo perl: avviando questo script, il processo di compilazione e installazione ha inizio.

Di seguito, un elenco dei moduli più comuni:

ExtUtils::MakeMaker

Build script
Template:Filename
CPAN Link
http://search.cpan.org/dist/ExtUtils-MakeMaker

Il primo, e più vecchio è sicuramente Template:Codeline. Il principale svantaggio di questo sistema, è che richiede l'utility Template:Filename affinché possa compilare ed installare il tutto. Benchè questo non sia un grande problema su un sistema Linux, può diventare problematico per utenti Windows! La comunità Perl sta cercando di incoraggiare l'uso di moduli più nuovi, che non hanno questo problema.

Module::Build

Build Script
Template:Filename
CPAN Link
http://search.cpan.org/dist/Module-Build

Il vantaggio principale derivante dall'uso di questo modulo, è che usa solamente perl e perciò non richiede l'utility Template:Filename per funzionare. Un tempo, la sua installazione era abbastanza difficoltosa, poichè non era possibile eseguire il build script senza averlo prima installato. Ad oggi, ciò non rappresenta più un problema, poichè Template:Codeline fa parte dei core modules.

Module::Install

Build Script
Template:Filename
CPAN Link
http://search.cpan.org/dist/Module-Install

Di recente introduzione, Template:Codeline richiede che Template:Filename sia installato per funzionare. È stato scritto per essere un sostituto naturale di Template:Codeline, oltre che per compensare alcune delle sue mancanze.

Una caratteristica molto interessante di questo modulo, è che ne viene fornita una copia all'interno del dist package, cosicchè, a differenza dei moduli sopra menzionati, non è necessario installarlo nel sistema.

Un'altra caratteristica di rilievo è l'auto-install. Anche se l'uso di questa feature non è raccomandato, questa viene usata molto spesso. Quando l'autore del modulo ne abilita l'uso, Template:Codeline procederà alla ricerca e all'installazione di tutti i moduli richiesti che non siano presenti al momento dell'esecuzione di Template:Filename. Benchè questa funzione venga disabilitata quando Template:Codeline viene eseguito da Template:Codeline o Template:Codeline, ciò non accade se viene utilizzato all'interno di un PKGBUILD! Si veda PERL_AUTOINSTALL per risolvere il problema.

Variabili d'ambiente

Alcune variabili di sistema, possono influenzare il modo in cui i moduli sono compilati o installati, e potrebbero causare problemi inaspettati se usate in modo scorretto, specialmente all'interno di un Template:Filename.

PERL_MM_USE_DEFAULT

Quando questa variabile ha valore "true", i sistemi di installazione dei moduli descritti sopra, risponderanno ad eventuali domande con una risposta affermativa.

PERL_AUTOINSTALL

È possibile passare degli argomenti a linea di comando aggiuntivi a Template:Codeline attraverso questa variabile. Per disattivare l'auto-install (altamente consigliato), si assegni il valore Template:Codeline a questa variabile.

export PERL_AUTOINSTALL="--skipdeps"

PERL_MM_OPT

Questa variabile consente, similmente a PERL_AUTOINSTALL, di passare degli argomenti al sistema di build. Per esempio, è possibile installare i moduli nella propria home directory usando:

export PERL_MM_OPT=INSTALLBASE=~/perl5

PERL_MB_OPT

Uguale a PERL_MM_OPT, questa variabile è riservata a Template:Codeline. Come sopra, per installare i moduli nella propria home directory:

export PERL_MB_OPT=--install_base=~/perl5

MODULEBUILDRC

Template:Codeline permette di scavalcare gli argomenti a riga di comando con un file di configurazione. Di default, questo è Template:Filename. È possibile definire un file di configurazione personalizzato inserendone il percorso in Template:Codeline.

Esempio rinforzato

Usando le nozioni appena acquisite, è possibile creare un PKGBUILD che resisterà a qualunque tentativo di sabotaggio da parte delle variabili d'ambiente:

# Contributor: Your Name <youremail@domain.com>
pkgname=perl-foo-bar
pkgver=VERSION
pkgrel=1
pkgdesc='This is the awesome Foo::Bar module!'
arch=('any')
url='http://search.cpan.org/dist/Foo-Bar'
license=('GPL' 'PerlArtistic')
depends=('perl>=5.10.0')
makedepends=()
provides=()
conflicts=()
replaces=()
backup=()
options=(!emptydirs)
install=
source=("http://search.cpan.org/CPAN/authors/id/***/***-$pkgver.tar.gz")
md5sums=()

build() {
  cd "$srcdir/***-$pkgver"
  
  # Setting these env variables overwrites any command-line-options we don't want...
  export PERL_MM_USE_DEFAULT=1 PERL_AUTOINSTALL=--skipdeps \
    PERL_MM_OPT="INSTALLDIRS=vendor DESTDIR='$pkgdir'" \
    PERL_MB_OPT="--installdirs vendor --destdir '$pkgdir'" \
    MODULEBUILDRC=/dev/null

  # If using Makefile.PL
  { /usr/bin/perl Makefile.PL &&
    make &&
    make test &&
    make install; } || return 1

  # If using Build.PL
  { /usr/bin/perl Build.PL &&
    ./Build &&
    ./Build test &&
    ./Build install; } || return 1

  # remove perllocal.pod and .packlist
  find "$pkgdir" -name .packlist -o -name perllocal.pod -delete