Próximo: , Anterior: , Acima: Diretrizes de empacotamento   [Conteúdo][Índice]


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

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. Python 2 packages are being removed from the distribution; please do no not submit any new Python 2 packages.

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.

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


Próximo: Módulos Perl, Anterior: Emacs Packages, Acima: Diretrizes de empacotamento   [Conteúdo][Índice]