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

Informações de dependências para pacotes Python estão geralmente disponíveis na árvore de fonte do pacote, com variados graus de precisão nos arquivos: setup.py, requirements.txt ou tox.ini (este último principalmente para testes de dependência).

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.

Atualmente empacotamos Python com setuptools e pip instalados por padrão. Isto está prestes a mudar, e os usuários são encorajados a usar o python-toolchain se quiserem um ambiente de construção para 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.
Pacotes Python necessários apenas em tempo de compilação — e.g., aqueles listados sob build-system.requires no pyproject.toml ou com a palavra-chave setup_requires no setup.py — ou dependencias apenas para teste — e.g., aqueles no tests_require ou no tox.ini — vão no native-inputs. A razão é que (1) eles não precisam ser propagados porque não são necessários em tempo de execução e (2) em um contexto de compilação cruzada, é a entrada “nativa” que nós queríamo.
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).