Módulos Python (Manual de referência do GNU Guix)

22.8.8 Módulos Python

Atualmente empacotamos Python 2 e Python 3, sob os nomes de variável Scheme python-2 e python conforme explicado em Números de versão. Para evitar confusão e conflitos de nomes com outras linguagens de programação, parece desejável que o nome de um pacote para um módulo Python contenha a palavra python.

Alguns módulos são compatíveis com apenas uma versão do Python, outros com ambas. Se o pacote Foo for compilado com Python 3, nós o nomeamos python-foo. Se ele for compilado com Python 2, nós o nomeamos python2-foo. Pacotes Python 2 estão sendo removidos da distribuição; por favor, não envie nenhum pacote Python 2 novo.

Se um projeto já contém a palavra python, nós a descartamos; por exemplo, o módulo python-dateutil é empacotado sob os nomes python-dateutil e python2-dateutil. Se o nome do projeto começa com py (p.ex., pytz), nós o mantemos e o prefixamos conforme descrito acima.

Nota: Atualmente, há dois sistemas de construção diferentes para pacotes Python no Guix: python-build-system e pyproject-build-system. Por muito tempo, os pacotes Python foram construídos a partir de um arquivo setup.py especificado informalmente. Isso funcionou incrivelmente bem, considerando o sucesso do Python, mas era difícil construir ferramentas em torno dele. Como resultado, uma série de sistemas de construção alternativos surgiram e a comunidade eventualmente decidiu por um padrão formal para especificar os requisitos de construção. pyproject-build-system é a implementação do Guix desse padrão. Ele é considerado “experimental”, pois ainda não suporta todos os vários backends de construção PEP-517, mas você é encorajado a experimentá-lo para novos pacotes Python e relatar quaisquer problemas. Ele eventualmente será descontinuado e mesclado ao python-build-system.

Especificando dependências

22.8.8.1 Especificando dependências

Dependency information for Python packages is usually available in the package source tree, with varying degrees of accuracy: in the pyproject.toml file, the setup.py file, in requirements.txt, or in tox.ini (the latter mostly for test dependencies).

Sua missão, ao escrever uma receita para um pacote Python, é mapear essas dependências para o tipo apropriado de “entrada” (veja inputs). Apesar do importador do pypi normalmente fazer um bom trabalho (veja Invoking guix import), você pode se interessar em verificar a lista de verificação a seguir para determinar qual dependência vai onde.

We currently package Python with setuptools and pip installed per default. This is about to change, and users are encouraged to use python-toolchain if they want a build environment for Python.
guix lint avisará se setuptools ou pip forem adicionados como entradas nativas porque geralmente não são necessários.
Dependências de Python necessárias em tempo de execução vão em propagated-inputs. Elas geralmente são definidas com a palavra-chave install_requires em setup.py ou no arquivo requirements.txt.
Python packages required only at build time—e.g., those listed under build-system.requires in pyproject.toml or with the setup_requires keyword in setup.py—or dependencies only for testing—e.g., those in tests_require or tox.ini—go into native-inputs. The rationale is that (1) they do not need to be propagated because they are not needed at run time, and (2) in a cross-compilation context, it’s the “native” input that we’d want.
Exemplos são os frameworks de teste pytest, mock e nose. É claro, se qualquer um desses pacotes também for necessário em tempo de compilação, ele precisa ir para propagated-inputs.
Qualquer coisa que não encaixar nas categorias anteriores vai para inputs. Por exemplo, programas ou bibliotecas C necessárias para compilar pacotes Python contendo extensões C.
Se um pacote Python tem dependências opcionais (extras_require), fica a seu critério adicioná-las ou não, com base na sua proporção de utilidade/sobrecarga (veja guix size).