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

From ArchWiki
Jump to: navigation, search
(Background)
(10 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
[[Category:Package development (Italiano)]]
 
[[Category:Package development (Italiano)]]
[[Category:Guidelines (Italiano)]]
+
[[en:Lisp Package Guidelines]]
 
+
{{i18n|Lisp Package Guidelines}}
+
{{translateme}}
+
{{Nota|Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese.}}
+
 
+
 
== Introduzione ==
 
== Introduzione ==
  
 
Attualmente ci sono relativamente pochi pacchetti lisp disponibili nei repository di Arch. Questo significa che prima o poi, probabilmente, se ne aggiungeranno altri. E' dunque utile pensare, adesso che ce ne sono pochi, a come dovrebbero essere pacchettizzati. Questa pagina vuole essere un punto di riferimento sulle linee guida per i pacchetti lisp. E' bene comunque tenere a mente che questa non è una versione definitiva; se non siete d'accordo con alcune idee suggerite qui, sentitevi liberi di modificare la pagina e proporre qualcosa di migliore.
 
Attualmente ci sono relativamente pochi pacchetti lisp disponibili nei repository di Arch. Questo significa che prima o poi, probabilmente, se ne aggiungeranno altri. E' dunque utile pensare, adesso che ce ne sono pochi, a come dovrebbero essere pacchettizzati. Questa pagina vuole essere un punto di riferimento sulle linee guida per i pacchetti lisp. E' bene comunque tenere a mente che questa non è una versione definitiva; se non siete d'accordo con alcune idee suggerite qui, sentitevi liberi di modificare la pagina e proporre qualcosa di migliore.
  
== Directory Structure and Naming ==
+
== Struttura delle cartelle e nomi ==
  
There is at least one package in the base repository (libgpg-error)
+
C'è almeno un pacchetto nel repository base (libgpg-errpor) che include dei file lisp, che sono posizionati in '''/usr/share/common-lisp/source/gpg-error'''. Per conformità, gli altri pacchetti lisp dovrebbero installare i propri files in '''/usr/share/common-lisp/source/'''. Ogni pacchetto dovrebbe avere la propria cartella, in modo da non creare disordine in questa cartella di base.
that includes lisp files, which are placed in
+
'''/usr/share/common-lisp/source/gpg-error'''. In keeping with this,
+
other lisp packages should also place their files in
+
'''/usr/share/common-lisp/source/'''. Each package should have its own
+
directory, so as not to clutter up this base directory.
+
  
The package directory
+
La cartella del pacchetto dovrebbe avere lo stesso nome del pacchetto lisp, e non dovrebbe essere nominata come nel repository Arch (o AUR). Questo si applica anche ai pacchetti costituiti soltanto da un file.
should be the name of the lisp package, not what it's called in the
+
Arch repository (or AUR). This applies even to single-file packages.
+
  
For example, a Lisp package called '''cl-ppcre''' should be called
+
Ad esempio, un pacchetto Lisp chiamato '''cl-ppcre''' dovrebbe essere nominato '''cl-ppcre''' in AUR e risiedere in '''/usr/share/common-lisp/source/cl-ppcre'''. Un pacchetto chiamato '''alexandria''' dovrebbe essere nominato '''cl-alexandria''' in AUR e risiedere in in '''/usr/share/common-lisp/source/alexandria'''.
'''cl-ppcre''' in AUR and reside in '''/usr/share/common-lisp/source/cl-ppcre'''.
+
A Lisp package called '''alexandria''' should be called '''cl-alexandria'''
+
in AUR and reside in '''/usr/share/common-lisp/source/alexandria'''.
+
  
 
== ASDF ==
 
== ASDF ==
  
Try to avoid the usage of ASDF-Install as a means of installing these
+
Cercare di evitare l'utilizzo di ASDF-Install per l'installazione di questi pacchetti
system-wide packages.
+
di sistema.
  
ASDF itself may be necessary or helpful as a means of compiling and/or
+
ASDF può essere necessario o utile per la compilazione e/o il caricamento di pacchetti. In questo caso, è consigliabile che la cartella usata per il registro centrale (la posizione di tutti i link simbolici a *.asd) sia '''/usr/share/common-lisp/systems/'''.
loading packages. In that case, it is suggested that the directory
+
used for the central registry (the location of all of the symlinks
+
to *.asd) be '''/usr/share/common-lisp/systems/'''.
+
  
However, I have observed problems with doing the compilation with asdf
+
Sono stati riscontrati problemi effettuando la compilazione con asdf come parte del processo di compilazione di un pacchetto. Si può risolvere attraverso l'uso di un file package.install di questo tipo:  
as a part of the package compilation process. However, it does work
+
during an install, through use of a package.install file. Such a file
+
might look like this:
+
  
 
  # cl-ppcre.install
 
  # cl-ppcre.install
Line 78: Line 57:
 
  $op $*
 
  $op $*
  
Of course, for this example to work, there needs to be a symlink to
+
Naturalmente, per far funzionare questo esempio, è necessario avere un link simbolico a package.asd nella cartella di sistema di asdf. Durante la compilazione del pacchetto, questo dovrebbe risolvere...
package.asd in the asdf system directory. During package compilation,
+
a stanza such as this will do the trick...
+
  
 
  pushd ${_lispdir}/systems
 
  pushd ${_lispdir}/systems
Line 87: Line 64:
 
  popd
 
  popd
  
...where ''$_lispdir'' is '''${startdir}/pkg/usr/share/common-lisp'''.
+
...dove ''$_lispdir'' è '''${startdir}/pkg/usr/share/common-lisp'''.
By linking to a relative, rather than an absolute, path, it's possible
+
Creando un link con un path relativo piuttosto che assoluto, è possibile garantire che il link rimanga valido anche dopo l'installazione.
to guarantee that the link will not break post-install.
+
  
== Lisp-specific packaging ==
+
== Packaging per versioni specifiche di Lisp ==
  
When possible, do not make packages specific to a single lisp
+
Quando possibile, non creare pacchetti relativi ad una singola implementazione di lisp, cercare di essere indipendenti dall piattaforma per quanto il pacchetto lo permetta.
implementation; try to be as cross-platform as the package itself will
+
Se, nonostante tutto, il pacchetto è specificatamente pensato per una singola implementazione di lisp (ad esempio, gli sviluppatori non hanno ancora aggiunto il supporto per altre implementazioni, o il pacchetto è stato sviluppato per fornire una funzionalità già presente in altre implementazioni), è corretto fare il proprio pacchetto Arch specifico per una particolare implementazione di lisp.
allow. If, however, the package is specifically designed for a single
+
lisp implementation (i.e., the developers haven't gotten around to
+
adding support for others yet, or the package's purpose is
+
specifically to provide a capability that is built in to another lisp
+
implementation), it is appropriate to make your Arch package
+
lisp-specific.
+
  
To avoid making packages implementation-specific, ideally all
+
Per evitare di creare pacchetti specifici per una particolare implementazione, idealmente i pacchetti relativi a tutte le implementazioni (SBCL, cmucl, clisp) dovrebbero essere creati con il campo del PKGBUILD '''common-lisp'''. Comunque, non è il caso (e questo potrebbe creare problemi alla persone che preferiscono avere implementazioni multiple di lisp a portata di mano). Allo stesso tempo, si potrebbe (a) non rendere il proprio pacchetto dipendente da nessun lisp e includere nel package.install un messaggio che richieda l'installazione di lisp (non ottimale) opppure (b) seguire l'esempio del PKGBUILD di ''sbcl'' e includere un controllo condizionale per capire quale lisp è necessario (che è una soluzione complessa e, ancora, non ottimale). Altre idee sono le benvenute.  
implementation packages (SBCL, cmucl, clisp) would be built with the
+
PKGBUILD field '''common-lisp'''. However, that's not the case (and
+
that would likely cause problems for people who prefer to have
+
multiple lisps at their fingertips). In the meantime, you could (a)
+
not make your package depend on *any* lisp and include a statement in
+
the package.install file telling folks to make sure they have a lisp
+
installed (not ideal), or (b) Take direction from the ''sbcl''
+
PKGBUILD and include a conditional statement to figure out which lisp
+
is needed (which is hackish and, again, far from ideal). Other ideas
+
are welcome.
+
  
Also note that if ASDF is needed to install/compile/load the package,
+
C'è anche da notare che se ASDF è necessario per installare/compilare/caricare il pacchetto le cose possono potenzialmente diventare più complicate a causa delle dipendenze, dal momento che SBCL viene fornito con asdf, clisp no ma c'è un pacchetto in AUR, e CMUCL potrebbe o meno fornirlo. (Purtroppo l'autore di questa pagina non conosce praticamente niente di CMUCL; mi dispiace).
things could potentially get awkward as far as dependencies go, since
+
SBCL comes with asdf installed, clisp does not but there is an AUR
+
package, and CMUCL may or may not have it (the author of this doc.
+
knows next to nothing about CMUCL; sorry).
+
  
People currently maintaining lisp-specific packages that don't need to
+
Le persone che stanno attualmente mantenendo dei pacchetti lisp relativi ad una particolare implementazione di lisp ma che non necessitano di una particolare implementazione per funzionare potrebbero considerare di fare almeno una delle seguenti cose:  
be lisp-specific should consider doing at least one of the following:
+
  
* Editing their PKGBUILD(s) to be cross-platform, provided someone else is not already maintaining the same package for a different lisp.
+
* Modificare i propri PKGBUILD(s) per essere indipendenti dalla piattaforma, assicurandosi che qualcun'altro che non stia già mantenendo lo stesso pacchetto per un'implementazione diversa.
  
* Offering to take over maintenance or help with maintenance of the same package for a different lisp, and then combining them into a single package.
+
* Offrirsi di farsi carico o aiutare con il mantenimento di versioni dello stesso pacchetto anche per altre implementazioni di lisp e combinarle in un unico pacchetto
  
* Offering up their package to the maintainer of a different lisp's version of the same package, so as to allow that person to combine them into a single package.
+
* Offire il proprio pacchetto al maintainer di una versione dello stesso pacchetto per un'altra implementazione, in modo da permettergli di combinarle in un unico pacchetto.
  
(Note that joyfulgirl, the author of this doc., currently maintains
+
(Notare che joyfulgirl, l'autrice di questo documento, che attualmente mantiene le versioni per clisp di cl-ppcre e stumpwm; è disponibile sia a donare questi pacchetti ai maintainer delle versioni SBCL oppure mantenere la nuova versione indipendente dalla piattaforma da sola se i maintainer delle versione SBCL non se ne vogliono fare carico)
clisp versions of cl-ppcre and of stumpwm; she is open to either
+
giving up the packages to the maintainers of the SBCL versions or to
+
maintain the new, cross-platform versions herself if the SBCL-version
+
maintainers don't want to).
+
  
== Things you, the reader, can do ==
+
== Cose che l'utente può fare ==
  
* Maintain lisp packages following these guidelines
+
* Mantenere pacchetti lisp seguendo queste linee-guida.
* Update and fix problems with these guidelines
+
* Aggiornare e correggere queste linee-guida
* Keep up with what's changed here
+
* Seguire i cambiamenti di questa pagina
* Provide (polite) thoughts, feedback, and suggestions both on this document and to people's work.
+
* Fornire (educatamente) consigli, pareri e suggerimenti sia su questo documento che sul lavoro delle persone
* Translate this page and future updates to this page.
+
* Tradurre questa pagina e futuri aggiornamenti a questa pagina.

Revision as of 11:41, 13 June 2012

Introduzione

Attualmente ci sono relativamente pochi pacchetti lisp disponibili nei repository di Arch. Questo significa che prima o poi, probabilmente, se ne aggiungeranno altri. E' dunque utile pensare, adesso che ce ne sono pochi, a come dovrebbero essere pacchettizzati. Questa pagina vuole essere un punto di riferimento sulle linee guida per i pacchetti lisp. E' bene comunque tenere a mente che questa non è una versione definitiva; se non siete d'accordo con alcune idee suggerite qui, sentitevi liberi di modificare la pagina e proporre qualcosa di migliore.

Struttura delle cartelle e nomi

C'è almeno un pacchetto nel repository base (libgpg-errpor) che include dei file lisp, che sono posizionati in /usr/share/common-lisp/source/gpg-error. Per conformità, gli altri pacchetti lisp dovrebbero installare i propri files in /usr/share/common-lisp/source/. Ogni pacchetto dovrebbe avere la propria cartella, in modo da non creare disordine in questa cartella di base.

La cartella del pacchetto dovrebbe avere lo stesso nome del pacchetto lisp, e non dovrebbe essere nominata come nel repository Arch (o AUR). Questo si applica anche ai pacchetti costituiti soltanto da un file.

Ad esempio, un pacchetto Lisp chiamato cl-ppcre dovrebbe essere nominato cl-ppcre in AUR e risiedere in /usr/share/common-lisp/source/cl-ppcre. Un pacchetto chiamato alexandria dovrebbe essere nominato cl-alexandria in AUR e risiedere in in /usr/share/common-lisp/source/alexandria.

ASDF

Cercare di evitare l'utilizzo di ASDF-Install per l'installazione di questi pacchetti di sistema.

ASDF può essere necessario o utile per la compilazione e/o il caricamento di pacchetti. In questo caso, è consigliabile che la cartella usata per il registro centrale (la posizione di tutti i link simbolici a *.asd) sia /usr/share/common-lisp/systems/.

Sono stati riscontrati problemi effettuando la compilazione con asdf come parte del processo di compilazione di un pacchetto. Si può risolvere attraverso l'uso di un file package.install di questo tipo:

# cl-ppcre.install
# arg 1:  the new package version
post_install() {
    echo "---> Compiling lisp files <---"

    clisp --silent -norc -x \
        "(load #p\"/usr/share/common-lisp/source/asdf/asdf\") \
        (pushnew #p\"/usr/share/common-lisp/systems/\" asdf:*central-registry* :test #'equal) \
        (asdf:operate 'asdf:compile-op 'cl-ppcre)"

    echo "---> Done compiling lisp files <---"

    cat << EOM

    To load this library, load asdf and then place the following lines
    in your ~/.clisprc.lisp file:

    (push #p"/usr/share/common-lisp/systems/" asdf:*central-registry*)
    (asdf:operate 'asdf:load-op 'cl-ppcre)
EOM
}

post_upgrade() {
    post_install $1
}

pre_remove() {
    rm /usr/share/common-lisp/source/cl-ppcre/{*.fas,*.lib}
}

op=$1
shift

$op $*

Naturalmente, per far funzionare questo esempio, è necessario avere un link simbolico a package.asd nella cartella di sistema di asdf. Durante la compilazione del pacchetto, questo dovrebbe risolvere...

pushd ${_lispdir}/systems
ln -s ../source/cl-ppcre/cl-ppcre.asd .
ln -s ../source/cl-ppcre/cl-ppcre-test.asd .
popd

...dove $_lispdir è ${startdir}/pkg/usr/share/common-lisp. Creando un link con un path relativo piuttosto che assoluto, è possibile garantire che il link rimanga valido anche dopo l'installazione.

Packaging per versioni specifiche di Lisp

Quando possibile, non creare pacchetti relativi ad una singola implementazione di lisp, cercare di essere indipendenti dall piattaforma per quanto il pacchetto lo permetta. Se, nonostante tutto, il pacchetto è specificatamente pensato per una singola implementazione di lisp (ad esempio, gli sviluppatori non hanno ancora aggiunto il supporto per altre implementazioni, o il pacchetto è stato sviluppato per fornire una funzionalità già presente in altre implementazioni), è corretto fare il proprio pacchetto Arch specifico per una particolare implementazione di lisp.

Per evitare di creare pacchetti specifici per una particolare implementazione, idealmente i pacchetti relativi a tutte le implementazioni (SBCL, cmucl, clisp) dovrebbero essere creati con il campo del PKGBUILD common-lisp. Comunque, non è il caso (e questo potrebbe creare problemi alla persone che preferiscono avere implementazioni multiple di lisp a portata di mano). Allo stesso tempo, si potrebbe (a) non rendere il proprio pacchetto dipendente da nessun lisp e includere nel package.install un messaggio che richieda l'installazione di lisp (non ottimale) opppure (b) seguire l'esempio del PKGBUILD di sbcl e includere un controllo condizionale per capire quale lisp è necessario (che è una soluzione complessa e, ancora, non ottimale). Altre idee sono le benvenute.

C'è anche da notare che se ASDF è necessario per installare/compilare/caricare il pacchetto le cose possono potenzialmente diventare più complicate a causa delle dipendenze, dal momento che SBCL viene fornito con asdf, clisp no ma c'è un pacchetto in AUR, e CMUCL potrebbe o meno fornirlo. (Purtroppo l'autore di questa pagina non conosce praticamente niente di CMUCL; mi dispiace).

Le persone che stanno attualmente mantenendo dei pacchetti lisp relativi ad una particolare implementazione di lisp ma che non necessitano di una particolare implementazione per funzionare potrebbero considerare di fare almeno una delle seguenti cose:

  • Modificare i propri PKGBUILD(s) per essere indipendenti dalla piattaforma, assicurandosi che qualcun'altro che non stia già mantenendo lo stesso pacchetto per un'implementazione diversa.
  • Offrirsi di farsi carico o aiutare con il mantenimento di versioni dello stesso pacchetto anche per altre implementazioni di lisp e combinarle in un unico pacchetto
  • Offire il proprio pacchetto al maintainer di una versione dello stesso pacchetto per un'altra implementazione, in modo da permettergli di combinarle in un unico pacchetto.

(Notare che joyfulgirl, l'autrice di questo documento, che attualmente mantiene le versioni per clisp di cl-ppcre e stumpwm; è disponibile sia a donare questi pacchetti ai maintainer delle versioni SBCL oppure mantenere la nuova versione indipendente dalla piattaforma da sola se i maintainer delle versione SBCL non se ne vogliono fare carico)

Cose che l'utente può fare

  • Mantenere pacchetti lisp seguendo queste linee-guida.
  • Aggiornare e correggere queste linee-guida
  • Seguire i cambiamenti di questa pagina
  • Fornire (educatamente) consigli, pareri e suggerimenti sia su questo documento che sul lavoro delle persone
  • Tradurre questa pagina e futuri aggiornamenti a questa pagina.