Python package guidelines (Português)
CLR – Cross – Eclipse – Free Pascal – GNOME – Go – Haskell – Java – KDE – Kernel – Lisp – MinGW – Node.js – Nonfree – OCaml – Perl – PHP – Python – Ruby – VCS – Web – Wine
Esse documento cobre padrões e diretrizes na escrita de PKGBUILDs para softwares Python.
Contents
Nome do pacote
Para bibliotecas Python 3 use python-nomemódulo
. Use também o prefixo se o pacote fornecer um programa fortemente acoplado ao ecossistema Python (por exemplo, pip ou tox). Para outros aplicativos, use apenas o nome do programa. Em ambos os casos, o nome do pacote deve ser completamente minúsculo.
O mesmo se aplica a somente Python 2, mas o prefixo (se necessário) é python2-
.
Pacotes versionados
Se você precisar adicionar um pacote versionado, use python-nomemódulo-versão
(ex.: python-colorama-0.2.5
). Então, uma dependência python colorama==0.2.5
vai se tornar em um pacote Arch python-colorama-0.2.5
.
Métodos de instalação
Os pacotes Python geralmente são instalados usando ferramentas específicas da linguagem, como pip ou easy_install, que são comparáveis aos gerenciadores de pacotes dedicados na medida em que foram projetados para buscar os arquivos fonte de um repositório online (geralmente PyPI, o Python Package Index) e rastrear o arquivos relevantes (para uma comparação detalhada entre os dois, veja pip vs easy_install).
No entanto, para gerenciar pacotes Python dentro de PKGBUILDs, o distutils fornecido de forma padrão é a solução mais conveniente, pois usa o setup.py
do pacote fonte baixado e instala facilmente arquivos no diretório $pkgdir/usr/lib/python<versão python>/site-packages/$pkgname
.
distutils
Um exemplo de PKGBUILD com distutils pode ser encontrado aqui. Ele segue a forma:
<versão python> setup.py install --root="$pkgdir/" --optimize=1
sendo que:
- <versão python> é substituído com o binário correto,
python
oupython2
-
--root="$pkgdir/"
evita a tentativa de instalar diretamente no sistema hospedeiro em vez do arquivo de pacote, que resultaria em um erro de permissão -
--optimize=1
compila arquivos.pyo
de forma que eles possam ser rastreados pelo pacman.
setuptools
A cena de empacotamento de Python migrou em grande parte do distutils para o setuptools, que está ativamente desenvolvido e funciona como uma importação de substituição ao setup.py
. A principal diferença para os empacotadores é que setuptools é empacotado separadamente do próprio Python e deve ser especificado como um makedepends
.
Se o pacote resultante incluir executáveis que importam o módulo pkg_resources
, os setuptools devem ser adicionalmente especificados como depends
das funções de package_*()
divididas; alternativamente, se o PKGBUILD apenas instalar o pacote Python para uma única versão do Python, setuptools deve ser movido de makedepends
para depends
.
pip
Se você precisar usar o pip (fornecido por python-pip e python2-pip) para, por exemplo, instalar pacotes wheel, lembre-se de passar as seguintes opções:
PIP_CONFIG_FILE=/dev/null pip install --isolated --root="$pkgdir" --ignore-installed --no-deps *.whl
-
PIP_CONFIG_FILE=/dev/null
ignora{/etc,~/.config}/pip.conf
, o qual pode estar anexando sinalizadores arbitrários ao pip. -
--isolated
ignora variáveis de ambiente (e, novamente,{/etc,~/.config}/pip/pip.conf
) que, do contrário, poderia também estar anexando sinalizadores arbitrários ao pip. -
--ignore-installed
é necessário até https://github.com/pypa/pip/issues/3063 estar resolvido (do contrário, pip ignora a instalação na presença de uma instalação--user
anterior). -
--no-deps
assegura que dependências não sejam empacotadas junto com pacote principal.
pip não sabe como gerar arquivos .pyo
(veja https://github.com/pypa/pip/issues/2209). Para gerá-los manualmente após pip ter instalado o módulo, execute:
python -O -m compileall "${pkgdir}/caminho/para/o/módulo
Notas
Na maioria dos casos, você deve colocar any
no vetor arch
, já que a maioria dos pacotes Python são independentes da arquitetura.
Não instale um diretório chamado apenas tests
, pois ele facilmente entra em conflito com outros pacotes Python (por exemplo, /usr/lib/python2.7/site-packages/tests/
).
URLs de download do PyPI
URL PyPI na forma https://pypi.python.org/packages/source/${_name:0:1}/${_name}/${_name}-${pkgver}.tar.gz
foram abandonados silenciosamente para novas versões de pacotes no curso de 2016, substituídos por um esquema usando um hash impredizível que precisa ser obtido do site do PYPI toda vez que um pacote precisa ser atualizado[1].
Como os empacotadores downstream relataram seus problemas aos mantenedores do PyPI[2], um novo esquema estável foi fornecido[3]: PKGBUILD (Português)#source o vetor source=()
deve agora usar os modelos de URL a seguir.
Note que uma variável $_name
personalizada é usada em vez de $pkgname
já que pacotes python são geralmente chamados python-$_name
.
- Pacote fonte
https://files.pythonhosted.org/packages/source/${_name::1}/${_name}/${_name}-${pkgver}.tar.gz
- Pacote wheel bilingual (compatível com Python 2 e Python 3)
https://files.pythonhosted.org/packages/py2.py3/${_name::1}/$_name/$_name-$pkgver-$_name-$pkgver-py2.py3-none-any.whl
- Pacote wheel específico para arquitetura
- neste exemplo para
source_x86_64=('...')
. Também_py=py36
pode ser usado para não repetir a versão do python: https://files.pythonhosted.org/packages/$_py/${_name::1}/$_name/$_name-$pkgver-$_py-${_py}m-manylinux1_x86_64.whl