Python package guidelines (Português)
CLR – Cross – Eclipse – Electron – Free Pascal – GNOME – Go – Haskell – Java – KDE – Kernel – Lisp – MinGW – Node.js – Nonfree – OCaml – Perl – PHP – Python – R – Ruby – Rust – VCS – Web – Wine
Esse documento cobre padrões e diretrizes na escrita de PKGBUILDs para softwares Python.
Contents
Nome do pacote
Para módulos de biblioteca do Python 3, use python-nomemódulo
. Também use o prefixo se o pacote fornece um programa fortemente atrelado ao ecossistema do Python (p. ex. pip or tox). Para outros aplicativos, use apenas o nome do programa.
O mesmo se aplica para Python 2, exceto que 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 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 PKGBUILD de distutils é geralmente bem simples:
build() { python setup.py build } package() { python setup.py install --root="$pkgdir/" --optimize=1 --skip-build }
sendo que:
- 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 bytecode otimizados (.pyo
para Python 2,opt-1.pyc
para Python 3) de forma que eles possam ser rastreados pelo pacman.--skip-build
otimiza, evitando tentativas desnecessárias de reexecutar as etapas de compilação já executadas na funçãobuild()
.
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.
- 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
Note que uma variável personalizada $_name
é usada em vez de pkgname
já que nomes de pacotes python são geralmente prefixados com python-
. Essa variável pode ser definida genericamente da seguinte forma:
_name=${pkgname#python-}