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

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

Some modules are compatible with only one version of Python, others with both. If the package Foo is compiled with Python 3, we name it python-foo. If it is compiled with Python 2, we name it python2-foo. Packages should be added when they are necessary; we don’t add Python 2 variants of the package unless we are going to use them.

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: Currently there are two different build systems for Python packages in Guix: python-build-system and pyproject-build-system. For the longest time, Python packages were built from an informally specified setup.py file. That worked amazingly well, considering Python’s success, but was difficult to build tooling around. As a result, a host of alternative build systems emerged and the community eventually settled on a formal standard for specifying build requirements. pyproject-build-system is Guix’s implementation of this standard. It is considered “experimental” in that it does not yet support all the various PEP-517 build backends, but you are encouraged to try it for new Python packages and report any problems. It will eventually be deprecated and merged into python-build-system.

Especificando dependências

22.4.7.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” (see inputs). Apesar do importador do pypi normalmente fazer um bom trabalho (see 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 will warn if setuptools or pip are added as native-inputs because they are generally not necessary.
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 (see guix size).