Lisp package guidelines (Português)

From ArchWiki
Jump to: navigation, search
Status de tradução: Esse artigo é uma tradução de Lisp package guidelines. Data da última tradução: 2018-11-02. Você pode ajudar a sincronizar a tradução, se houver alterações na versão em inglês.
Diretrizes de criação de pacotes

CLRCrossEclipseFree PascalGNOMEGoHaskellJavaKDEKernelLispMinGWNode.jsNonfreeOCamlPerlPHPPythonRRubyVCSWebWine

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.

Para evitar tornar os pacotes específicos da implementação, idealmente todos os pacotes de implementação (SBCL, cmucl, clisp) seriam construídos com o campo PKGBUILD common-lisp. No entanto, esse não é o caso (e isso provavelmente causaria problemas para pessoas que preferem ter vários lisps na ponta dos dedos). Enquanto isso, 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 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, já que o SBCL vem com asdf instalado, enquanto o clisp não, mas há um pacote AUR e a CMUCL pode ou não tê-lo.

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.