Python package guidelines (Português)

Esse documento cobre padrões e diretrizes na escrita de PKGBUILDs para softwares Python.

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-.

Nota: O nome do pacote deve estar todo em minúsculo.

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 ou python2
• --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ção build().

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-}