Lisp package guidelines (Português)

From ArchWiki
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.
Status de tradução: Esse artigo é uma tradução de Lisp package guidelines. Data da última tradução: 2019-06-27. Você pode ajudar a sincronizar a tradução, se houver alterações na versão em inglês.
Diretrizes de pacotes do Arch

32-bitCLRCMakeCrossDKMSEclipseElectronFonteFree PascalGNOMEGoHaskellJavaKDEKernelLispMesonMinGWNode.jsNonfreeOCamlPerlPHPPythonRRubyRustVCSWebWine

No momento, há relativamente poucos pacotes Lisp disponíveis nos repositórios do Arch. Isso significa que, em algum momento ou outro, mais provavelmente aparecerá. É útil, portanto, descobrir agora, enquanto há poucos pacotes, como eles devem ser empacotados.

Nomenclatura e estrutura de diretórios

Há pelo menos um pacote no repositório base (libgpg-error) que inclui arquivos lisp, que são colocados em /usr/share/common-lisp/source/gpg-error. De acordo com isso, outros pacotes lisp também devem colocar seus arquivos em /usr/share/common-lisp/source/pkgname.

O diretório do pacote deve ser o nome do pacote lisp, não o que é chamado nos repositórios oficiais do Arch (ou no AUR). Isso se aplica até mesmo a pacotes de arquivo único.

Por exemplo, um pacote Lisp chamado "cl-ppcre" deve ser chamado cl-ppcre no AUR e residir em /usr/share/common-lisp/source/cl-ppcre. Um pacote Lisp chamado "alexandria" deve ser chamado cl-alexandria no AUR e residir em /usr/share/common-lisp/source/alexandria.

ASDF

Tente evitar o uso do ASDF-Install como um meio de instalar esses pacotes em todo o sistema.

O próprio ASDF pode ser necessário ou útil como meio de compilar e/ou carregar pacotes. Nesse caso, sugere-se que o diretório usado para o registro central (a localização de todos os links simbólicos para *.asd) seja /usr/share/common-lisp/systems/.

No entanto, tenho observado problemas em fazer a compilação com asdf como parte do processo de compilação de pacotes. No entanto, ele funciona durante uma instalação, através do uso de um arquivo pacote.install. Esse arquivo pode ser assim:

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 $*

Obviamente, para este exemplo funcionar, é necessário que haja um link simbólico para pacote.asd no diretório do sistema asdf. Durante a compilação do pacote, um bloco como essa fará o truque...

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

...sendo que $_lispdir é $pkgdir/usr/share/common-lisp. Ao vincular a um caminho relativo, em vez de absoluto, é possível garantir que o link não interromperá a pós-instalação.

Empacotamento específico do Lisp

Quando possível, não crie pacotes específicos para uma única implementação de lisp; tente ser tão multiplataforma quanto o próprio pacote permitir. Se, no entanto, o pacote for projetado especificamente para uma implementação única de lisp (ou seja, os desenvolvedores ainda não conseguiram adicionar suporte para outros, ou o propósito do pacote é especificamente fornecer um recurso integrado a outra implementação de lisp), é apropriado tornar o seu pacote Arch específico de lisp.

Se o pacote é independente da implementação, deve depender de common-lisp. Se o pacote possui suporte a várias implementações, mas não todas, você poderia (a) não fazer com que seu pacote dependa de *qualquer* lisp e incluir uma declaração no arquivo package.install informando às pessoas para ter certeza de que possuem um lisp compatível instalado (não ideal) ou (b) se baseie no PKGBUILD do sbcl e inclua uma declaração condicional para descobrir qual lisp é necessário (que envolve muito hacking e, novamente, longe do ideal). Outras ideias são bem-vindas.

Observe também que se o ASDF for necessário para instalar/compilar/carregar o pacote, as coisas podem ficar estranhas no que diz respeito às dependências. SBCL e CMUCL vêm com asdf instalado, mas o clisp não (mas há um pacote AUR).

As pessoas que atualmente mantêm pacotes específicos de lisp que não precisam ser específicos de lisp devem considerar fazer pelo menos um dos seguintes procedimentos:

  • Editar seus PKGBUILDs para serem multiplataformas, desde que outra pessoa não esteja mantendo o mesmo pacote para um lisp diferente.
  • Se oferecer para assumir a manutenção ou ajudar na manutenção do mesmo pacote para um lisp diferente e, em seguida, combiná-los em um único pacote.
  • Oferecer seu pacote ao mantenedor de uma versão diferente do mesmo pacote, para permitir que essa pessoa os combine em um único pacote.

Coisas que você, o leitor, pode fazer

  • Manter pacotes lisp seguindo essas diretrizes
  • Atualizar e corrigir problemas com essas diretrizes
  • Se manter atualizado com o que foi alterado aqui
  • Fornecer ideias, feedback e sugestões (educados) tanto para esse documento quanto para o trabalho das pessoas.
  • Traduzir essa página e atualizações futuras a esta página.