Módulos Python (Manual de referencia de GNU Guix)

22.4.7 Módulos Python

Actualmente empaquetamos Python 2 y Python 3, bajo los nombres de variable Scheme python-2 y python como se explica en Versiones numéricas. Para evitar confusiones y conflictos de nombres con otros lenguajes de programación, parece deseable que el nombre de paquete para un módulo Python contenga la palabra python.

Algunos módulos son compatibles únicamente con una versión de Python, otros con ambas. Si el paquete Foo se compila únicamente con Python 3, lo llamamos python-foo. Si se compila con Python 2, lo llamamos python2-foo. Los paquetes deben añadirse cuando sean necesarios; no añadimos la variante de Python 2 del paquete a menos que vayamos a usarla.

Si un proyecto ya contiene la palabra python, la eliminamos; por ejemplo, el módulo python-dateutil se empaqueta con los nombres python-dateutil y python2-dateutil. Si el nombre del proyecto empieza con py (por ejemplo pytz), este se mantiene y el prefijo es el especificado anteriormente..

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.

Especificación de dependencias

22.4.7.1 Especificación de dependencias

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

Su misión, cuando escriba una receta para un paquete Python, es asociar estas dependencias con el tipo apropiado de “entrada” (see inputs). Aunque el importador de pypi normalmente hace un buen trabajo (see Invocación de guix import), puede querer comprobar la siguiente lista para determinar qué dependencia va dónde.

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.
Las dependencias Python requeridas en tiempo de ejecución van en propagated-inputs. Típicamente están definidas con la palabra clave install_requires en setup.py, o en el archivo 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.
Ejemplos son las bibliotecas de pruebas pytest, mock y nose. Por supuesto, si alguno de estos paquetes también se necesita en tiempo de ejecución, necesita ir en propagated-inputs.
Todo lo que no caiga en las categorías anteriores va a inputs, por ejemplo programas o bibliotecas C requeridas para construir los paquetes Python que contienen extensiones C.
Si un paquete Python tiene dependencias opcionales (extras_require), queda en su mano decidir si las añade o no, en base a la relación utilidad/sobrecarga (see guix size).