Gentoo Logo

Guía Gentoo para desarrolladores Python

Contenido:

1.  Incrementos, eliminaciones, estabilización

Incrementos de versión y corrección de errores

Nunca incremente la versión de los siguientes paquetes si no se le ha indicado expresamente por un (Co-)Responsable:

  • dev-lang/python
  • app-admin/eselect-python

Aunque el hecho de realizar incrementos de versión, será apreciado con toda seguridad, no lo haga a ciegas. Hay muchos errores en el pasado que se han ido conservando a lo largo de las versiones sin que se hayan notificado. Asegúrese de que comprueba bugzilla antes de incrementar la versión, para comprobar si hay errores pendientes para ese paquete. Leer el ChangeLog del paquete es una buena idea para cazar dependencias nuevas, modificadas u opcionales.

No todas las ebuilds existentes en el árbol usan las eclasses de forma adecuada (mire abajo), por lo que, por favor, elimine los errores que encuentre. Construya el paquete al cual quiere incrementar la versión o incluso corregir errores en pequeños cambios. No todas las ebuilds se han escrito de forma correcta y otras, por el contrario, estaban perfectas cuando se han incluido en el árbol. Sin embargo, a lo largo del tiempo la práctica y las reglas cambian.

Lo mismo se aplica a la hora de corregir errores en ebuilds. Por favor, compruebe que hay una nueva versión del paquete y haga el cambio de versión de forma adecuada. Cerrar informes de error está muy bien, pero no es suficiente. Su primer objetivo no es cerrar informes de bugs, sino mantener los paquetes de su grupo.

Pida y realice revisiones. Con esta práctica, la calidad de la ebuilds aumenta y es una excelente forma de transmitir conocimiento.

Eliminando versiones antiguas y estabilización

Cada miembro del equipo debe tratar de mantener los directorios de los paquetes limpios y agrupados. Aparte de los chequeos normales (la última versión estable para una arquitectura, la última versión que no está enmascarada, otros paquetes dependiendo de una versión exacta de este paquete), hay otras cosas que debe considerar antes de eliminar una versión antigua:

  • Cuando se elimina una versión inestable en presencia de una estable: ¿Tiene la versión que quiere eliminar errores serios que impiden la estabilización?. De lo contrario puede mantenerla y abrir un informe para realizar la estabilización.
  • La misma consideración aplica si no existe una versión estable aún: ¿Existen usuarios que deseen una versión estable?. ¿Es el paquete lo suficiente maduro para ser estable?. Si decide estabilizarlo, piense también de qué forma cada equipo de arquitectura podría probarlo.
  • No estabilice versiones alfa o beta ni tampoco versiones candidatas siempre que sea posible. Hay excepciones a esto (si el equipo de desarrollo principal sólo produce versiones beta del paquete o el paquete es desesperadamente necesitado para otra aplicación). En caso de duda, en primer lugar hable con el responsable.

2.  Escribiendo ebuilds

Tipos de paquetes

Hay dos tipos de paquetes gestionados por python.eclass:

  • Paquetes que soportan la instalación de múltiples versiones de Python
  • Paquetes que no soportan la instalación de múltiples versiones de Python

Los paquetes que soportan la instalación de múltiples versiones de Python instalan algunos ficheros (normalmente .py o .so) en directorios específicos a las versiones dadas de Python.

Los paquetes que no soportan la instalación de múltiples versiones de Python normalmente muestran al menos una de las siguientes propiedades:

  • Instalan los módulos de Python fuera de los directorios site-packages.
  • No instalan ningún fichero en los directorios específicos a las versiones dadas de Python.
  • Instalan librerías enlazadas con la librería de Python (p.e. libpython2.7.so) fuera de los directorios específicos a las versiones dadas de Python (p.e. en /usr/lib) y los nombres de fichero de estas librerías no contienen la versión de Python.
  • Importan módulos de Python instalados por paquetes que no soportan la instalación de múltiples versiones de Python.

Especificación de la dependencia de Python

Los ebuilds deben especificar adecuadamente sus dependencias de la(s) versión(es) soportada(s) de Python. python.eclass soporta la variable de ayuda PYTHON_DEPEND, la cual permite especificar una versión minimal y maximal de Python. La variable PYTHON_DEPEND debe definirse antes de 'inherit'. La variable PYTHON_DEPEND debe contener uno o dos grupos de componentes de versión que pueden comenzar opcionalmente con el ajuste USE condicional de la forma "flag? " o "!flag? ". Cada grupo de componentes de versión debe incluir una versión superior ("2", "3" or "*") y puede opcionalmente contener una versión minimal (p.e. "2.6") y una versión maximal (p.e. "3.1"). Los componentes de version deben estar separados por dos puntos. Los dos puntos seguidos únicamente por componentes vacíos pueden ser omitidos. La versión superior "*" indica que las versiones de Python 2 y Python 3 son aceptadas. Las versiones minimales y maximales deberían contener versiones superiores e inferiores.

Listado de Código 2.1: Ejemplos de PYTHON_DEPEND

# Dependencia de cualquier versión de Python.
PYTHON_DEPEND="*"

# Dependencia de cualquier versión de Python 2.
PYTHON_DEPEND="2"

# Dependencia de cualquier versión de Python 3.
PYTHON_DEPEND="3"

# Dependencia de cualquier versión de Python 2, por lo menos la 2.6.*.
PYTHON_DEPEND="2:2.6"

# Dependencia de cualquier versión de Python 3, por lo menos la 3.2.*.
PYTHON_DEPEND="3:3.2"

# Dependencia de cualquier versión de Python 2 or 3, por lo menos la 2.6.*.
PYTHON_DEPEND="*:2.6"

# Dependencia de cualquier versión de Python 2, por lo menos la 2.7.*, o
una versión de Python 3, por lo menos la 3.2.*.
PYTHON_DEPEND="2:2.7 3:3.2"

# Dependencia de cualquier versión de Python 2, a lo sumo la 2.6.*.
PYTHON_DEPEND="2::2.6"

# Dependencia de cualquier versión de Python 3, a lo sumo la 3.2.*.
PYTHON_DEPEND="3::3.2"

# Dependencia de cualquier versión de Python 2 or 3, a lo sumo la 3.2.*.
PYTHON_DEPEND="*::3.2"

# Dependencia de cualquier versión de Python 2, por lo menos la 2.5.* y a lo
sumo la 2.6.*.
PYTHON_DEPEND="2:2.5:2.6"

# Dependencia de cualquier versión de Python 3, por lo menos la 3.1.* y a lo
sumo la 3.2.*.
PYTHON_DEPEND="3:3.1:3.2"

# Dependencia de cualquier versión de Python 2 or 3, por lo menos la 2.6.* y
a lo sumo la 3.1.*.
PYTHON_DEPEND="*:2.6:3.1"

# Dependencia de cualquier versión de Python 2, por lo menos la 2.5.* y a lo
sumo la 2.6.*, o una versión de Python 3, por lo menos la 3.1.* y a lo sumo
la 3.2.*.
PYTHON_DEPEND="2:2.5:2.6 3:3.1:3.2"

# Dependencia de cualquier versión de Python 2, cuando el ajuste USE
"python" está habilitado.
PYTHON_DEPEND="python? 2"

# Dependencia de cualquier versión de Python 2, por lo menos la 2.5.*,
cuando el ajuste USE "python" USE flag está habilitado.
PYTHON_DEPEND="python? 2:2.5"

# Dependencia de cualquier versión de Python 3, cuando el ajuste USE
"minimal" está deshabilitado.
PYTHON_DEPEND="!minimal? 3"

Comprobando los ajustes USE de Python

Los ebuilds pueden definir PYTHON_USE_WITH o PYTHON_USE_WITH_OR antes que 'inherit' y llamar a python_pkg_setup() para comprobar si se ha instalado Python con ajustes USE específicos. Todos los ajustes USE especificados en PYTHON_USE_WITH deben estar habilitados, por otro lado, al menos un ajuste USE especificado en PYTHON_USE_WITH_OR debe estar habilitado. PYTHON_USE_WITH_OPT puede especificar el nombre de un ajuste USE, el cual condiciona PYTHON_USE_WITH y PYTHON_USE_WITH_OR. Si se usa python_set_active_version() (descrita más abajo), entonces debe llamarse antes que python_pkg_setup().

Listado de Código 2.2: Ejemplo de PYTHON_USE_WITH (comprobar Tkinter)

PYTHON_USE_WITH="tk"

inherit python

...

pkg_setup() {
    python_set_active_version 2
    python_pkg_setup
}

Soportando la instalación de múltiples versiones de Python

Los ebuilds deben definir SUPPORT_PYTHON_ABIS="1" antes que 'inherit'.

Los ebuilds que no funcionen con algunas versiones de Python deben ajustar la variable RESTRICT_PYTHON_ABIS (p.e. después de DEPEND/RDEPEND), la cual debe contener una lista de patrones fnmatch separados por espacios. Estos patrones pueden contener el carácter '*'.

Listado de Código 2.3: Ejemplos de RESTRICT_PYTHON_ABIS

# Paquete que no soporta Python 2.4.
RESTRICT_PYTHON_ABIS="2.4"

# Paquete que no soporta Python 3.
RESTRICT_PYTHON_ABIS="3.*"

# Paquete que no soporta Python 2.4 ni 2.5.
RESTRICT_PYTHON_ABIS="2.[45]"

# Paquete que no soporta Python 2.4 ni 3.
RESTRICT_PYTHON_ABIS="2.4 3.*"

# Paquete que no soporta Python 2.4, 2.6, 2.7 ni 3.
RESTRICT_PYTHON_ABIS="2.4 2.[67] 3.*"

Se deben usar distintos directorios de construcción para cada versión de Python. Distutils por defecto usar el directorio "build", que puede ser modificado con la opción "-b" option del comando "build" de setup.py. Los paquetes que no usan Distutils, y un número muy pequeño de paquetes que usan Distutils, normalmente necesitan usar directorios de construcción fuera de "${S}". Las funciones de distutils.eclass por defecto usan los directorios "${S}/build-${PYTHON_ABI}". Los paquetes que no usan los directorios "${S}/build-${PYTHON_ABI}" necesitan llamar a la función python_copy_sources(), la cual copia los fuentes a directorios de construcción separados.

Listado de Código 2.4: Ejemplo de python_copy_sources()

src_prepare() {
    epatch "${FILESDIR}/${P}-fix_build.patch"
    python_copy_sources
}

Se puede usar python_copy_sources() para copiar un subdirectorio de "${S}" a directorios de construcción separados. Puede ser de utilidad en ebuilds de paquetes que opcionalmente construyen cubiertas (bindings) de Python.

Listado de Código 2.5: Ejemplo de python_copy_sources() con un subdirectorio de "${S}"

src_prepare() {
    default

    if use python; then
        python_copy_sources bindings/python
    fi
}

La función python_execute_function() se usa para realizar acciones apropiadas con todas las versiones activas de Python. Esta función necesita un argumento: el nombre de la función o la opción -d / --default-function. Esta función acepta algunos argumentos opcionales. python_execute_function() ejecuta una función, que debe estar definida previamente. Para mejorar la legibilidad, se recomienda definir funciones que se usan únicamente en un lugar de las ebuilds, antes de pasar sus nombres a python_execute_function().

Listado de Código 2.6: Ejemplo de python_execute_function()

src_test() {
    testing() {
        PYTHONPATH="build-${PYTHON_ABI}/lib" "$(PYTHON)" runtests.py
    }
    python_execute_function testing
}

Cuando se necesita ejecutar acciones en directorios de construcción separados creados con python_copy_sources(), entonces se debe pasar la opción -s / --separate-build-dirs a python_execute_function().

Listado de Código 2.7: Ejemplo de python_execute_function() con la opción -s

src_prepare() {
    epatch "${FILESDIR}/${P}-fix_syntax.patch"
    python_copy_sources
}
src_configure() {
    configuration() {
        "$(PYTHON)" configure.py \
            --bindir="${EPREFIX}/usr/bin" \
            --destdir="${EPREFIX}$(python_get_sitedir)"
    }
    python_execute_function -s configuration
}

Si los directorios de construcción son subdirectorios de "${S}", entonces se deben pasar además la opción --source-dir y el camino a la función python_execute_function().

Listado de Código 2.8: Ejemplo de python_execute_function() con -s y --source-dir options

src_configure() {
    econf \
        $(use_with java) \
        $(use_with python) \
        $(use_with ruby)

    # Las cubiertas (bindings) de Python son construidas/comprobadas/instaladas manualmente.
    sed -e "/SUBDIRS =/s/ python//" -i bindings/Makefile || die "sed failed"
}

src_compile() {
    default

    if use python; then
        python_copy_sources bindings/python
        building() {
            # Ignorar los caminos almacenados por 'configure' en los ficheros bindings/python-${PYTHON_ABI}/Makefile.
            emake PYTHON="$(PYTHON)" PYTHON_INCLUDEDIR="$(python_get_includedir)" PYTHON_LIBDIR="$(python_get_libdir)"
        }
        python_execute_function -s --source-dir bindings/python building
    fi
}

La opción -d / --default-function es útil en algunos casos, cuando las mismas acciones que son ejecutadas en las funciones fase por defecto (p.e. emake en src_compile()), necesitan ser ejecutadas. Esta opción únicamente se puede usar en un subconjunto de las fases del ebuild.

Listado de Código 2.9: Ejemplo de python_execute_function() con la opción -d

src_compile() {
    python_execute_function -d -s
}

python.eclass define las siguientes funciones fases que pueden ser usadas para simplificar algunos ebuilds.

  • python_src_prepare
  • python_src_configure
  • python_src_compile
  • python_src_test
  • python_src_install

La función python_src_prepare() llama a 'python_copy_sources', mientras que otras funciones fase llaman a 'python_execute_function -d -s'. Si la variable PYTHON_EXPORT_PHASE_FUNCTIONS="1" ha sido definida antes que 'inherit', entonces estas funciones fase son exportadas.

La variable PYTHON_ABI puede ser comprobada dentro de la función ejecutada por python_execute_function().

Listado de Código 2.10: Ejemplo de python_execute_function() con una fucnión que comprueba PYTHON_ABI

src_prepare() {
    python_copy_sources

    patching() {
        [[ "${PYTHON_ABI}" == 3.* ]] && return
        epatch "${FILESDIR}/${P}-python-3.patch"
    }
    python_execute_function --action-message 'Applying patches with $(python_get_implementation) $(python_get_version)' -s patching
}

Importante: Las opciones --action-message y --failure-message de python_execute_function() aceptan argumentos que son evaluados internamente por lo que las comillas simples pueden ser de gran utilidad.

En ocasiones otra eclass define una función especializada, la cual realiza la construcción, instalación, etc., sin embargo, está diseñada para paquetes que no son Python. En estos casos es posible llamar a python_execute_function() con el nombre de esta función.

Listado de Código 2.11: Ejemplo de python_execute_function() con una función de otra eclass

src_configure() {
    python_execute_function -s gnome2_src_configure
}

Ajustando la versión activa de Python en paquetes que no soportan la instalación de múltiples versiones de Python

Si el paquete en cuestión soporta únicamente Python 2 o Python 3, entonces se debe llamar a la función python_set_active_version() para definir la versión activa de Python. Normalmente la versión mayor de Python debe ser pasada a esta función.

Listado de Código 2.12: Ejemplo de python_set_active_version() con una versión mayor de Python

pkg_setup() {
    python_set_active_version 2
}

Si un paquete soporta únicamente una versión de Python, entonces la ABI Python (de la forma ${major_version}.${minor_version}) se puede pasar a python_set_active_version(). Esto causará que el python-updater ignorará este paquete.

Listado de Código 2.13: Ejemplo de python_set_active_version() con ABI Python

pkg_setup() {
    python_set_active_version 3.1
}

Funciones para obtener datos

  • PYTHON muestra el nombre de fichero del intérprete de PYTHON (p.e. python3.2).
  • PYTHON con la opción -a / --absolute-path muestra el camino absoluto al intérprete Python (p.e. /usr/bin/python3.2).
  • python_get_implementation muestra el nombre de la implementación de Python (p.e. CPython).
  • python_get_implementational_package muestra la categoría, el nombre y el zócalo (slot) del paquete que ofrece la implementación de Python (p.e. dev-lang/python:3.2).
  • python_get_includedir muestra el camino al directorio include de Python (p.e. /usr/include/python3.2).
  • python_get_libdir muestra el camino a la directorio de librería de Python (p.e. /usr/lib64/python3.2).
  • python_get_sitedir muestra el camino al directorio site-packages de Python (p.e. /usr/lib64/python3.2/site-packages).
  • python_get_library muestra el camino a la librería de Python (p.e. /usr/lib64/libpython3.2.so).
  • python_get_library con la opción -l / --linker-option muestra la librería de Python library de la forma preparada para la opción -l${librería} del enlazador (p.e. -lpython3.2).
  • python_get_version muestra la versión mayor y menor de Python (p.e. 3.2).
  • python_get_version con la opción --major muestra la versión mayor de Python (p.e. 3).
  • python_get_version con la opción --minor muestra la versión menor de Python (p.e. 2).
  • python_get_version con la opción --micro muestra la versión micro de Python (p.e. 0).

Listado de Código 2.14: Ejemplo de python_get_includedir()

src_install() {
    ...

    install_headers() {
        insinto "$(python_get_includedir)"
        doins include/*.h
    }
    python_execute_function -q install_headers
}

Importante: To call Python interpreter in ebuilds, "$(PYTHON)" should be used.

En los ebuilds que soportan la instalación de múltiples versiones de Python, en algunas ocasiones las acciones se deben ejecutar una única vez (p.e. la generación de documentación). En estos casos, la ejecución se debe realizar con la ABI final de Python de la lista de ABIs habilitadas, lo cual se realiza pasando la opción -f / --final-ABI a las funciones de obtención apropiadas.

Listado de Código 2.15: Ejemplo de PYTHON() con la opción -f

src_compile() {
    distutils_src_compile

    if use doc; then
        "$(PYTHON -f)" setup.py pudge
    fi
}

Intérprete usado (shebang) en guiones instalados

El intérprete usado (shebang, #!) en los guiones que se han instalado debería se correcto para evitar problemas cuando una versión diferente de Python se define como la versión activa principal. Si el paquete no soporta algunas versiones de Python y la construcción instala guiones con uso de intérpretes (shebangs) muy genéricos, entonces se debe llamar a python_convert_shebangs() para convertir estos "shebangs". Esta función requiere la versión de Python y los ficheros / directorios. Los directorios se pueden pasar únicamente con la opción -r / --recursive.

Listado de Código 2.16: Ejemplo de python_convert_shebangs()

src_prepare() {
    python_convert_shebangs -r 2 .
}

Manejando módulos compilados en bytes

La compilación byte de los módulos de Python está normalmente deshabilitada. python_enable_pyc() la habilita, mientras que python_disable_pyc() la deshabilita.

La función python_mod_optimize() se usa para compilar y optimizar los módulos Python en la fase pkg_postinst(). La función python_mod_cleanup() se usa para eliminar los módulos compilados y optimizados en pkg_postrm(). Los ebuilds que usan distutils.eclass e instalan módulos Python en los directorios site-packages, normalmente no necesitan llamar directamente a python_mod_optimize() o a python_mod_cleanup(). Los caminos de los módulos instalados en los directorios site-packages deben ser relativos a los directorios site-packages. Otros caminos deben ser relativos a ${ROOT}. La función python_mod_cleanup() elimina los directorios vacíos después de limpiar los ficheros .py.

Listado de Código 2.17: Ejemplo de python_mod_optimize() y python_mod_cleanup()

pkg_postinst() {
    python_mod_optimize PyQt4
}

pkg_postrm() {
    python_mod_cleanup PyQt4
}

Importante: Si el sistema de construcción del paquete realiza una compilación byte de los ficheros .py instalados, entonces es buena idea deshabilitar esta característica y usar python_mod_optimize() para evitar problemas inesperados.

Uso de distutils.eclass

  • Las funciones distutils_src_compile(), distutils_src_test() y distutils_src_install() realizan las acciones internas apropiadas para el tipo de paquete dado. En los ebuilds que soportan la instalación de múltiples versiones de Python, definen algunas funciones y pasan sus nombres a python_execute_function().
  • Si el nombre del ebuild (en ${PN}) difiere del directorio creado por el paquete en site-packages/, entonces este ebuild deberá definir una variable PYTHON_MODNAME para indicar a distutils_pkg_postinst() y a distutils_pkg_postrm() los caminos a los módulos Python.
  • Los ebuilds pueden definir la variable DOCS para indicar a distutils_src_install() que instale ficheros de documentación adicionales (en texto puro).

Listado de Código 2.18: Ejemplo de PYTHON_MODNAME (de dev-python/ipython)

PYTHON_MODNAME="IPython"

Nota: La función distutils_src_install() instala algunos ficheros de documentación por defecto.

Listado de Código 2.19: Ficheros de documentación instalados por defecto

default_docs="AUTHORS Change* CHANGELOG CONTRIBUTORS KNOWN_BUGS MAINTAINERS MANIFEST* NEWS PKG-INFO README* TODO"

3.  Problemas y fallos comunes

Abajo se indican algunos problemas comunes que se pueden encontrar y errores comunes que se comenten a la hora de escribir ebuilds para paquetes Python.

setuptools: *_require y use_setuptools()

Importante: Para setuptools-0.6a9 y superior no se necesita eliminar las opciones _require que no sean tests_require ya que a partir de esta versión --single-version-externally-managed es automática cuando se usa --root lo cual soluciona el problema. La nueva función distutils_src_unpack gestiona los problemas en use_setuptools(). Los métodos explicados en esta sección, esto es, la eliminación de _requires y use_setuptools() con sed, no deben ser usados más.

Los paquetes que usan setuptools para instalar, usan opciones _require como tests_require, install_require, setup_requires en setup.py. Están bien para aprender sobre dependencias, pero no los querrá en setup.py cuando esté instalando el paquete. Lo que sigue está extraído de la sección setup_requires en la página de setuptools:

Una cadena o lista de cadenas de texto especificando que otras distribuciones deben estar presentes para que el guión de configuración pueda ser ejecutado. setuptools intentará obtenerlos (incluso llegando al punto de descargarlos usando EasyInstall) antes de procesar el resto de los guiones de configuración o de los comandos.

—Guía de desarrollo de setuptools

Tenemos excelentes gestores de paquetes que pueden descargar información por nosotros y verificar los resúmenes de forma que no deseará descargar ningún paquete usando EasyInstall. Existen otras opciones como tests_require e install_requires que se comportan de la misma forma.

Algunos paquetes tienen un ez_setup.py junto con el usual setup.py. Se trata de un guión Python para descargar en instalar el setuptools apropiado. Para hacer esto use_setuptools() se invoca desde ez_setup.py antes de importar setuptools.

Listado de Código 3.1: use_setuptools() de ez_setup.py

def use_setuptools(
    version=DEFAULT_VERSION, download_base=DEFAULT_URL, to_dir=os.curdir,
    download_delay=15
):
    """Automatically find/download setuptools and make it available on sys.path
    [...]

Al igual que las opciones _require, si un guión setup.py script llama a a use_setuptools() desde ez_setup.py, entonces deberá eliminarlo. Abajo se muestra un ejemplo que ilustra cómo realizarlo.

Listado de Código 3.2: setup.py de dev-python/myghty-1.1

from ez_setup import use_setuptools
use_setuptools()
from setuptools import setup, find_packages

[...]

install_requires=["Routes >= 1.0", "Paste", "PasteDeploy", "PasteScript"],

[...]

Listado de Código 3.3: myghty-1.1.ebuild

src_unpack() {
    unpack ${A}
    cd "${S}"
    sed -i \
        -e '/use_setuptools/d' \
        -e '/install_requires=\[.*\],/d' \
        setup.py || die "sed failed"
}

src_test y PYTHONPATH

Cuando se prueban paquetes Python, es importante asegurarse de que estamos probando realmente el paquete que va a ser instalado no el que ya lo está. Podemos solucionar este problema ajustando la variable de entorno PYTHONPATH que aumenta el camino de búsqueda por defecto para los ficheros con módulos. Tenemos dos ejemplos:

Listado de Código 3.4: Ejemplo de src_test() de un módulo Python puro

src_test() {
    testing() {
        PYTHONPATH="build-${PYTHON_ABI}/lib" "$(PYTHON)" test.py
    }
    python_execute_function testing
}

Listado de Código 3.5: Ejemplo de src_test() de un módulo Python escrito en C

src_test() {
    testing() {
        PYTHONPATH="$(ls -d build-${PYTHON_ABI}/lib.*)" "$(PYTHON)" test.py
    }
    python_execute_function testing
}

Como ha podido comprobar, si el módulo está escrito en lenguajes como C, C++, etc, el nombre del directorio en la construcción varía entre arquitecturas, sin embargo siempre comienza por lib.

¿Es dev-python/setuptools un RDEPEND o un DEPEND?

El comando repoman puede mostrar una advertencia diciendo que dev-python/setuptools es un sospechoso de RDEPEND. Dese cuenta sin embargo de que setuptools es casi siempre una dependencia en tiempo de ejecución por código que instala comandos en /usr/bin, se usa pkg_resources para solicitar versiones específicas de paquetes o hacer uso de entradas en puntos de un sistema de plugins.

Si hace emerge de un paquete que usa setuptools e instala comandos en /usr/bin puede mirar estos comandos y determinar fácilmente si se requiere setuptools en tiempo de ejecución.

Listado de Código 3.6: Ejemplo de código que requiere setuptools en tiempo de ejecución

    #!/usr/bin/python
    # EASY-INSTALL-ENTRY-SCRIPT: 'doapfiend==0.3.4','console_scripts','doapfiend'
    __requires__ = 'doapfiend==0.3.4'
    import sys
    from pkg_resources import load_entry_point

Si el guión importa pkg_resources entonces dev-python/setuptools debe estar en RDEPEND.

Puede también usar dev-python/yolk para determinar si un paquete usar puntos de entrada a setuptools indicando el nombre del módulo Python (no el nombre del paquete Gentoo).

Listado de Código 3.7: Ejemplo de un módulo Python que requiere setuptools en tiempo deejecución

    $ yolk --entry-map paste

Si se produce alguna, entonces dev-python/setuptools debe estar en RDEPEND.



Imprimir

Página actualizada 28 de febrero, 2010

Sumario: Esta guía es una ayuda para los (nuevos) mantenedores de los paquetes de Python. Además ofrece valiosos consejos y trucos, contiene una serie de guías para incrementar versiones y eliminarlas, estabilización, uso correcto de eclass, dependencias y pruebas.

Tiziano Müller
Autor

Ali Polatel
Autor

Rob Cakebread
Autor

Arfrever Frehtes Taifersar Arahesis
Autor

José María Alonso
Traductor

Donate to support our development efforts.

Copyright 2001-2014 Gentoo Foundation, Inc. Questions, Comments? Contact us.