Siguiente: Módulos Perl, Anterior: snippets
frente a fases, Subir: Pautas de empaquetamiento [Índice general][Índice]
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..
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.
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.
propagated-inputs
. Típicamente están definidas con la palabra clave
install_requires
en setup.py, o en el archivo
requirements.txt.
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
.
inputs
, por
ejemplo programas o bibliotecas C requeridas para construir los paquetes
Python que contienen extensiones C.
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
).
Siguiente: Módulos Perl, Anterior: snippets
frente a fases, Subir: Pautas de empaquetamiento [Índice general][Índice]