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

16.4.7.1 Especificación de dependencias

La información de dependencias para paquetes Python está disponible habitualmente en el árbol de fuentes, con varios grados de precisión: en el archivo setup.py, en requirements.txt o en tox.ini.

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

• Actualmente empaquetamos con setuptools y pip instalados como Python 3.4 tiene por defecto. Por tanto no necesita especificar ninguno de ellos como entrada. guix lint le avisará si lo hace.
• 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.
• Los paquetes Python requeridos únicamente durante la construcción—por ejemplo, aquellos listados con la palabra clave setup_requires en setup.py—o únicamente para pruebas—por ejemplo, aquellos en tests_require—van en native-inputs. La razón es que (1) no necesitan ser propagados ya que no se requieren en tiempo de ejecución, y (2) en un entorno de compilación cruzada lo que necesitamos es la entrada “nativa”.

  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 (véase guix size).