* [gentoo-commits] gentoo commit in xml/htdocs/proj/es/Python: developersguide.xml
@ 2010-12-13 11:17 JosA MarAa Alonso (nimiux)
0 siblings, 0 replies; 2+ messages in thread
From: JosA MarAa Alonso (nimiux) @ 2010-12-13 11:17 UTC (permalink / raw
To: gentoo-commits
nimiux 10/12/13 11:17:44
Added: developersguide.xml
Log:
New spanish translation.
Revision Changes Path
1.1 xml/htdocs/proj/es/Python/developersguide.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/Python/developersguide.xml?rev=1.1&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/Python/developersguide.xml?rev=1.1&content-type=text/plain
Index: developersguide.xml
===================================================================
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/Python/developersguide.xml,v 1.1 2010/12/13 11:17:44 nimiux Exp $ -->
<guide link="/proj/en/Python/developersguide.xml" lang="es">
<title>Guía Gentoo para desarrolladores Python</title>
<author title="Autor">
<mail link="dev-zero@gentoo.org">Tiziano Müller</mail>
</author>
<author title="Autor">
<mail link="hawking@gentoo.org">Ali Polatel</mail>
</author>
<author title="Autor">
<mail link="pythonhead@gentoo.org">Rob Cakebread</mail>
</author>
<author title="Autor">
<mail link="arfrever@gentoo.org">Arfrever Frehtes Taifersar Arahesis</mail>
</author>
<author title="Traductor">
<mail link="nimiux"/>
</author>
<abstract>
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.
</abstract>
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
<license/>
<version>0.4</version>
<date>2010-02-28</date>
<chapter id="Bumps_Drops_Stabilization">
<title>Incrementos, eliminaciones, estabilización</title>
<section>
<title>Incrementos de versión y corrección de errores</title>
<body>
<p>
Nunca incremente la versión de los siguientes paquetes si no se le ha
indicado expresamente por un (Co-)Responsable:
</p>
<ul>
<li>dev-lang/python</li>
<li>app-admin/eselect-python</li>
</ul>
<p>
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 <b>antes</b> 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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
Pida y realice revisiones. Con esta práctica, la calidad de la ebuilds
aumenta y es una excelente forma de transmitir conocimiento.
</p>
</body>
</section>
<section>
<title>Eliminando versiones antiguas y estabilización</title>
<body>
<p>
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:
</p>
<ul>
<li>
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.
</li>
<li>
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.
</li>
<li>
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.
</li>
</ul>
</body>
</section>
</chapter>
<chapter id="Writing_of_ebuilds">
<title>Escribiendo ebuilds</title>
<section>
<title>Tipos de paquetes</title>
<body>
<p>
Hay dos tipos de paquetes gestionados por python.eclass:
</p>
<ul>
<li>
Paquetes que soportan la instalación de múltiples versiones de Python
</li>
<li>
Paquetes que no soportan la instalación de múltiples versiones de Python
</li>
</ul>
<p>
Los paquetes que soportan la instalación de múltiples versiones de Python
instalan algunos ficheros (normalmente <path>.py</path> o <path>.so</path>)
en directorios específicos a las versiones dadas de Python.
</p>
<p>
Los paquetes que no soportan la instalación de múltiples versiones de Python
normalmente muestran al menos una de las siguientes propiedades:
</p>
<ul>
<li>
Instalan los módulos de Python fuera de los directorios site-packages.
</li>
<li>
No instalan ningún fichero en los directorios específicos a las versiones
dadas de Python.
</li>
<li>
Instalan librerías enlazadas con la librería de Python
(p.e. <path>libpython2.7.so</path>) fuera de los directorios específicos a
las versiones dadas de Python (p.e. en <path>/usr/lib</path>) y los nombres
de fichero de estas librerías no contienen la versión de Python.
</li>
<li>
Importan módulos de Python instalados por paquetes que no soportan la
instalación de múltiples versiones de Python.
</li>
</ul>
</body>
</section>
<section>
<title>Especificación de la dependencia de Python</title>
<body>
<p>
Los ebuilds deben especificar adecuadamente sus dependencias de la(s)
versión(es) soportada(s) de Python. python.eclass soporta la variable de
ayuda <c>PYTHON_DEPEND</c>, la cual permite especificar una versión minimal
y maximal de Python. La variable <c>PYTHON_DEPEND</c> debe definirse antes
de 'inherit'. La variable <c>PYTHON_DEPEND</c> 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.
</p>
<pre caption="Ejemplos de PYTHON_DEPEND">
# Dependencia de cualquier versión de Python.
<ident>PYTHON_DEPEND</ident>="*"
# Dependencia de cualquier versión de Python 2.
<ident>PYTHON_DEPEND</ident>="2"
# Dependencia de cualquier versión de Python 3.
<ident>PYTHON_DEPEND</ident>="3"
# Dependencia de cualquier versión de Python 2, por lo menos la 2.6.*.
<ident>PYTHON_DEPEND</ident>="2:2.6"
# Dependencia de cualquier versión de Python 3, por lo menos la 3.2.*.
<ident>PYTHON_DEPEND</ident>="3:3.2"
# Dependencia de cualquier versión de Python 2 or 3, por lo menos la 2.6.*.
<ident>PYTHON_DEPEND</ident>="*: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.*.
<ident>PYTHON_DEPEND</ident>="2:2.7 3:3.2"
# Dependencia de cualquier versión de Python 2, a lo sumo la 2.6.*.
<ident>PYTHON_DEPEND</ident>="2::2.6"
# Dependencia de cualquier versión de Python 3, a lo sumo la 3.2.*.
<ident>PYTHON_DEPEND</ident>="3::3.2"
# Dependencia de cualquier versión de Python 2 or 3, a lo sumo la 3.2.*.
<ident>PYTHON_DEPEND</ident>="*::3.2"
# Dependencia de cualquier versión de Python 2, por lo menos la 2.5.* y a lo
sumo la 2.6.*.
<ident>PYTHON_DEPEND</ident>="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.*.
<ident>PYTHON_DEPEND</ident>="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.*.
<ident>PYTHON_DEPEND</ident>="*: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.*.
<ident>PYTHON_DEPEND</ident>="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.
<ident>PYTHON_DEPEND</ident>="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.
<ident>PYTHON_DEPEND</ident>="python? 2:2.5"
# Dependencia de cualquier versión de Python 3, cuando el ajuste USE
"minimal" está deshabilitado.
<ident>PYTHON_DEPEND</ident>="!minimal? 3"
</pre>
</body>
</section>
<section>
<title>Comprobando los ajustes USE de Python</title>
<body>
<p>
Los ebuilds pueden definir <c>PYTHON_USE_WITH</c> o
<c>PYTHON_USE_WITH_OR</c> antes que 'inherit' y llamar a
<b>python_pkg_setup()</b> 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. <c>PYTHON_USE_WITH_OPT</c> 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().
</p>
<pre caption="Ejemplo de PYTHON_USE_WITH (comprobar Tkinter)">
<ident>PYTHON_USE_WITH</ident>="tk"
<keyword>inherit</keyword> python
...
<stmt>pkg_setup</stmt>() {
<keyword>python_set_active_version</keyword> 2
<keyword>python_pkg_setup</keyword>
}
</pre>
</body>
</section>
<section>
<title>Soportando la instalación de múltiples versiones de Python</title>
<body>
<p>
Los ebuilds deben definir <c>SUPPORT_PYTHON_ABIS</c>="1" antes que
'inherit'.
</p>
<p>
Los ebuilds que no funcionen con algunas versiones de Python deben ajustar
la variable <c>RESTRICT_PYTHON_ABIS</c> (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 '*'.
</p>
<pre caption="Ejemplos de RESTRICT_PYTHON_ABIS">
# Paquete que no soporta Python 2.4.
<ident>RESTRICT_PYTHON_ABIS</ident>="2.4"
# Paquete que no soporta Python 3.
<ident>RESTRICT_PYTHON_ABIS</ident>="3.*"
# Paquete que no soporta Python 2.4 ni 2.5.
<ident>RESTRICT_PYTHON_ABIS</ident>="2.[45]"
# Paquete que no soporta Python 2.4 ni 3.
<ident>RESTRICT_PYTHON_ABIS</ident>="2.4 3.*"
# Paquete que no soporta Python 2.4, 2.6, 2.7 ni 3.
<ident>RESTRICT_PYTHON_ABIS</ident>="2.4 2.[67] 3.*"
</pre>
<p>
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
"<c>${S}/build-${PYTHON_ABI}</c>". Los paquetes que no usan los directorios
"${S}/build-${PYTHON_ABI}" necesitan llamar a la función
<b>python_copy_sources()</b>, la cual copia los fuentes a directorios de
construcción separados.
</p>
<pre caption="Ejemplo de python_copy_sources()">
<stmt>src_prepare</stmt>() {
<keyword>epatch</keyword> "<var>${FILESDIR}</var>/<var>${P}</var>-fix_build.patch"
<keyword>python_copy_sources</keyword>
}
</pre>
<p>
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.
</p>
<pre caption="Ejemplo de python_copy_sources() con un subdirectorio de "${S}"">
<stmt>src_prepare</stmt>() {
<keyword>default</keyword>
if <keyword>use</keyword> python; then
<keyword>python_copy_sources</keyword> bindings/python
fi
}
</pre>
<p>
La función <b>python_execute_function()</b> 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().
</p>
<pre caption="Ejemplo de python_execute_function()">
<stmt>src_test</stmt>() {
<stmt>testing</stmt>() {
<ident>PYTHONPATH</ident>="build-<var>${PYTHON_ABI}</var>/lib" "<keyword>$(PYTHON)</keyword>" runtests.py
}
<keyword>python_execute_function</keyword> testing
}
</pre>
<p>
Cuando se necesita ejecutar acciones en directorios de construcción
separados creados con python_copy_sources(), entonces se debe pasar la
opción <b>-s</b> / <b>--separate-build-dirs</b> a python_execute_function().
</p>
<pre caption="Ejemplo de python_execute_function() con la opción -s">
<stmt>src_prepare</stmt>() {
<keyword>epatch</keyword> "<var>${FILESDIR}</var>/<var>${P}</var>-fix_syntax.patch"
<keyword>python_copy_sources</keyword>
}
<stmt>src_configure</stmt>() {
<stmt>configuration</stmt>() {
"<keyword>$(PYTHON)</keyword>" configure.py \
--bindir="<var>${EPREFIX}</var>/usr/bin" \
--destdir="<var>${EPREFIX}</var>$(python_get_sitedir)"
}
<keyword>python_execute_function</keyword> -s configuration
}
</pre>
<p>
Si los directorios de construcción son subdirectorios de "${S}", entonces se
deben pasar además la opción <b>--source-dir</b> y el camino a la función
python_execute_function().
</p>
<pre caption="Ejemplo de python_execute_function() con -s y --source-dir options">
<stmt>src_configure</stmt>() {
<keyword>econf</keyword> \
$(use_with java) \
$(use_with python) \
$(use_with ruby)
<comment># Las cubiertas (bindings) de Python son construidas/comprobadas/instaladas manualmente.</comment>
<keyword>sed</keyword> -e "/SUBDIRS =/s/ python//" -i bindings/Makefile || <keyword>die</keyword> "sed failed"
}
<stmt>src_compile</stmt>() {
<keyword>default</keyword>
if <keyword>use</keyword> python; then
<keyword>python_copy_sources</keyword> bindings/python
<stmt>building</stmt>() {
<comment># Ignorar los caminos almacenados por 'configure' en los ficheros bindings/python-${PYTHON_ABI}/Makefile.</comment>
<keyword>emake</keyword> PYTHON="$(PYTHON)" PYTHON_INCLUDEDIR="$(python_get_includedir)" PYTHON_LIBDIR="$(python_get_libdir)"
}
<keyword>python_execute_function</keyword> -s --source-dir bindings/python building
fi
}
</pre>
<p>
La opción <b>-d</b> / <b>--default-function</b> 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.
</p>
<pre caption="Ejemplo de python_execute_function() con la opción -d">
<stmt>src_compile</stmt>() {
<keyword>python_execute_function</keyword> -d -s
}
</pre>
<p>
python.eclass define las siguientes funciones fases que pueden ser usadas
para simplificar algunos ebuilds.
</p>
<ul>
<li>python_src_prepare</li>
<li>python_src_configure</li>
<li>python_src_compile</li>
<li>python_src_test</li>
<li>python_src_install</li>
</ul>
<p>
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 <c>PYTHON_EXPORT_PHASE_FUNCTIONS</c>="1" ha sido definida antes que
'inherit', entonces estas funciones fase son exportadas.
</p>
<p>
La variable <c>PYTHON_ABI</c> puede ser comprobada dentro de la función
ejecutada por python_execute_function().
</p>
<pre caption="Ejemplo de python_execute_function() con una fucnión que comprueba PYTHON_ABI">
<stmt>src_prepare</stmt>() {
<keyword>python_copy_sources</keyword>
patching() {
[[ "<var>${PYTHON_ABI}</var>" == 3.* ]] && return
<keyword>epatch</keyword> "<var>${FILESDIR}</var>/<var>${P}</var>-python-3.patch"
}
<keyword>python_execute_function</keyword> --action-message 'Applying patches with $(python_get_implementation) $(python_get_version)' -s patching
}
</pre>
<impo>
Las opciones <b>--action-message</b> y <b>--failure-message</b> de
python_execute_function() aceptan argumentos que son evaluados internamente
por lo que las comillas simples pueden ser de gran utilidad.
</impo>
<p>
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.
</p>
<pre caption="Ejemplo de python_execute_function() con una función de otra eclass">
<stmt>src_configure</stmt>() {
<keyword>python_execute_function</keyword> -s gnome2_src_configure
}
</pre>
</body>
</section>
<section>
<title>Ajustando la versión activa de Python en paquetes que no soportan la
instalación de múltiples versiones de Python</title>
<body>
<p>
Si el paquete en cuestión soporta únicamente Python 2 o Python 3, entonces
se debe llamar a la función <b>python_set_active_version()</b> para definir
la versión activa de Python. Normalmente la versión mayor de Python debe ser
pasada a esta función.
</p>
<pre caption="Ejemplo de python_set_active_version() con una versión mayor de Python">
<stmt>pkg_setup</stmt>() {
<keyword>python_set_active_version</keyword> 2
}
</pre>
<p>
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.
</p>
<pre caption="Ejemplo de python_set_active_version() con ABI Python">
<stmt>pkg_setup</stmt>() {
<keyword>python_set_active_version</keyword> 3.1
}
</pre>
</body>
</section>
<section>
<title>Funciones para obtener datos</title>
<body>
<ul>
<li>
<b>PYTHON</b> muestra el nombre de fichero del intérprete de PYTHON
(p.e. <path>python3.2</path>).
</li>
<li>
<b>PYTHON</b> con la opción <b>-a</b> / <b>--absolute-path</b> muestra
el camino absoluto al intérprete Python
(p.e. <path>/usr/bin/python3.2</path>).
</li>
<li>
<b>python_get_implementation</b> muestra el nombre de la implementación
de Python (p.e. CPython).
</li>
<li>
<b>python_get_implementational_package</b> 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).
</li>
<li>
<b>python_get_includedir</b> muestra el camino al directorio include
de Python (p.e. <path>/usr/include/python3.2</path>).
</li>
<li>
<b>python_get_libdir</b> muestra el camino a la directorio de librería
de Python (p.e. <path>/usr/lib64/python3.2</path>).
</li>
<li>
<b>python_get_sitedir</b> muestra el camino al directorio site-packages
de Python (p.e. <path>/usr/lib64/python3.2/site-packages</path>).
</li>
<li>
<b>python_get_library</b> muestra el camino a la librería de Python
(p.e. <path>/usr/lib64/libpython3.2.so</path>).
</li>
<li>
<b>python_get_library</b> con la opción <b>-l</b> / <b>--linker-option</b>
muestra la librería de Python library de la forma preparada para la
opción -l${librería} del enlazador (p.e. -lpython3.2).
</li>
<li>
<b>python_get_version</b> muestra la versión mayor y menor de Python
(p.e. 3.2).
</li>
<li>
<b>python_get_version</b> con la opción <b>--major</b> muestra la versión
mayor de Python (p.e. 3).
</li>
<li>
<b>python_get_version</b> con la opción <b>--minor</b> muestra la versión
menor de Python (p.e. 2).
</li>
<li>
<b>python_get_version</b> con la opción <b>--micro</b> muestra la versión
micro de Python (p.e. 0).
</li>
</ul>
<pre caption="Ejemplo de python_get_includedir()">
<stmt>src_install</stmt>() {
...
<stmt>install_headers</stmt>() {
<keyword>insinto</keyword> "$(python_get_includedir)"
<keyword>doins</keyword> include/*.h
}
<keyword>python_execute_function</keyword> -q install_headers
}
</pre>
<impo>
To call Python interpreter in ebuilds, "<b>$(PYTHON)</b>" should be used.
</impo>
<p>
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 <b>-f</b> / <b>--final-ABI</b> a las funciones de
obtención apropiadas.
</p>
<pre caption="Ejemplo de PYTHON() con la opción -f">
<stmt>src_compile</stmt>() {
<keyword>distutils_src_compile</keyword>
if <keyword>use</keyword> doc; then
"<keyword>$(PYTHON -f)</keyword>" setup.py pudge
fi
}
</pre>
</body>
</section>
<section>
<title>Intérprete usado (shebang) en guiones instalados</title>
<body>
<p>
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
<b>python_convert_shebangs()</b> 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 <b>-r</b> /
<b>--recursive</b>.
</p>
<pre caption="Ejemplo de python_convert_shebangs()">
<stmt>src_prepare</stmt>() {
<keyword>python_convert_shebangs</keyword> -r 2 .
}
</pre>
</body>
</section>
<section>
<title>Manejando módulos compilados en bytes</title>
<body>
<p>
La compilación byte de los módulos de Python está normalmente
deshabilitada. <b>python_enable_pyc()</b> la habilita, mientras que
<b>python_disable_pyc()</b> la deshabilita.
</p>
<p>
La función <b>python_mod_optimize()</b> se usa para compilar y optimizar los
módulos Python en la fase pkg_postinst(). La función
<b>python_mod_cleanup()</b> 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 <path>.py</path>.
</p>
<pre caption="Ejemplo de python_mod_optimize() y python_mod_cleanup()">
<stmt>pkg_postinst()</stmt> {
<keyword>python_mod_optimize</keyword> PyQt4
}
<stmt>pkg_postrm()</stmt> {
<keyword>python_mod_cleanup</keyword> PyQt4
}
</pre>
<impo>
Si el sistema de construcción del paquete realiza una compilación byte de
los ficheros <path>.py</path> instalados, entonces es buena idea
deshabilitar esta característica y usar python_mod_optimize() para evitar
problemas inesperados.
</impo>
</body>
</section>
<section>
<title>Uso de distutils.eclass</title>
<body>
<ul>
<li>
Las funciones <b>distutils_src_compile()</b>, <b>distutils_src_test()</b>
y <b>distutils_src_install()</b> 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().
</li>
<li>
Si el nombre del ebuild (en ${PN}) difiere del directorio creado por el
paquete en <path>site-packages/</path>, entonces este ebuild deberá
definir una variable <c>PYTHON_MODNAME</c> para indicar a
<b>distutils_pkg_postinst()</b> y a <b>distutils_pkg_postrm()</b> los
caminos a los módulos Python.
</li>
<li>
Los ebuilds pueden definir la variable <c>DOCS</c> para indicar a
<b>distutils_src_install()</b> que instale ficheros de documentación
adicionales (en texto puro).
</li>
</ul>
<pre caption="Ejemplo de PYTHON_MODNAME (de dev-python/ipython)">
<ident>PYTHON_MODNAME</ident>="IPython"
</pre>
<note>
La función distutils_src_install() instala algunos ficheros de documentación
por defecto.
</note>
<pre caption="Ficheros de documentación instalados por defecto">
<ident>default_docs</ident>="AUTHORS Change* CHANGELOG CONTRIBUTORS KNOWN_BUGS MAINTAINERS MANIFEST* NEWS PKG-INFO README* TODO"
</pre>
</body>
</section>
</chapter>
<chapter id="Common_Problems_and_Mistakes">
<title>Problemas y fallos comunes</title>
<section>
<body>
<p>
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.
</p>
</body>
</section>
<section>
<title>setuptools: *_require y use_setuptools()</title>
<body>
<impo>
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.
</impo>
<p>
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
<b>setup_requires</b> en la <uri
link="http://peak.telecommunity.com/DevCenter/setuptools">página de
setuptools</uri>:
</p>
<p by="Guía de desarrollo 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 (<b>incluso llegando al
punto de descargarlos usando EasyInstall</b>) antes de procesar el resto de
los guiones de configuración o de los comandos.
</p>
<p>
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.
</p>
<p>
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.
</p>
<pre caption="use_setuptools() de ez_setup.py">
<keyword>def</keyword> <stmt>use_setuptools</stmt>(
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
[...]
</pre>
<p>
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.
</p>
<pre caption="setup.py de dev-python/myghty-1.1">
<keyword>from</keyword> ez_setup <keyword>import</keyword> use_setuptools
<stmt>use_setuptools</stmt>()
<keyword>from</keyword> setuptools <keyword>import</keyword> setup, find_packages
[...]
<ident>install_requires</ident>=["Routes >= 1.0", "Paste", "PasteDeploy", "PasteScript"],
[...]
</pre>
<pre caption="myghty-1.1.ebuild">
<stmt>src_unpack</stmt>() {
<keyword>unpack</keyword> <var>${A}</var>
<keyword>cd</keyword> "<var>${S}</var>"
<keyword>sed</keyword> -i \
-e '/use_setuptools/d' \
-e '/install_requires=\[.*\],/d' \
setup.py || <keyword>die</keyword> "sed failed"
}
</pre>
</body>
</section>
<section>
<title>src_test y PYTHONPATH</title>
<body>
<p>
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:
</p>
<pre caption="Ejemplo de src_test() de un módulo Python puro">
<stmt>src_test()</stmt> {
<stmt>testing</stmt>() {
<ident>PYTHONPATH</ident>="build-<var>${PYTHON_ABI}</var>/lib" "<keyword>$(PYTHON)</keyword>" test.py
}
<keyword>python_execute_function</keyword> testing
}
</pre>
<pre caption="Ejemplo de src_test() de un módulo Python escrito en C">
<stmt>src_test()</stmt> {
<stmt>testing</stmt>() {
<ident>PYTHONPATH</ident>="$(ls -d build-<var>${PYTHON_ABI}</var>/lib.*)" "<keyword>$(PYTHON)</keyword>" test.py
}
<keyword>python_execute_function</keyword> testing
}
</pre>
<p>
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 <path>lib</path>.
</p>
</body>
</section>
<section>
<title>¿Es dev-python/setuptools un RDEPEND o un DEPEND?</title>
<body>
<p>
El comando repoman puede mostrar una advertencia diciendo que
<c>dev-python/setuptools</c> es un sospechoso de RDEPEND. Dese cuenta sin
embargo de que <c>setuptools</c> 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.
</p>
<p>
Si hace emerge de un paquete que usa <c>setuptools</c> e instala comandos en
/usr/bin puede mirar estos comandos y determinar fácilmente si se requiere
<c>setuptools</c> en tiempo de ejecución.
</p>
<pre caption="Ejemplo de código que requiere setuptools en tiempo de ejecución">
<stmt>#!/usr/bin/python</stmt>
<stmt># EASY-INSTALL-ENTRY-SCRIPT: 'doapfiend==0.3.4','console_scripts','doapfiend'</stmt>
<ident>__requires__</ident> = 'doapfiend==0.3.4'
<stmt>import sys</stmt>
<stmt>from pkg_resources import load_entry_point</stmt>
</pre>
<p>
Si el guión importa <b>pkg_resources</b> entonces
<c>dev-python/setuptools</c> debe estar en RDEPEND.
</p>
<p>
Puede también usar <c>dev-python/yolk</c> para determinar si un paquete usar
puntos de entrada a <c>setuptools</c> indicando el nombre del <b>módulo</b>
Python (no el nombre del paquete Gentoo).
</p>
<pre caption="Ejemplo de un módulo Python que requiere setuptools en tiempo deejecución">
<stmt>$ yolk --entry-map paste</stmt>
</pre>
<p>
Si se produce alguna, entonces <c>dev-python/setuptools</c> debe estar en
RDEPEND.
</p>
</body>
</section>
</chapter>
</guide>
^ permalink raw reply [flat|nested] 2+ messages in thread
* [gentoo-commits] gentoo commit in xml/htdocs/proj/es/Python: developersguide.xml
@ 2012-10-28 15:21 Sven Vermeulen (swift)
0 siblings, 0 replies; 2+ messages in thread
From: Sven Vermeulen (swift) @ 2012-10-28 15:21 UTC (permalink / raw
To: gentoo-commits
swift 12/10/28 15:21:17
Modified: developersguide.xml
Log:
Removing link attribute from guides
Revision Changes Path
1.2 xml/htdocs/proj/es/Python/developersguide.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/Python/developersguide.xml?rev=1.2&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/Python/developersguide.xml?rev=1.2&content-type=text/plain
diff : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/Python/developersguide.xml?r1=1.1&r2=1.2
Index: developersguide.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/es/Python/developersguide.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- developersguide.xml 13 Dec 2010 11:17:44 -0000 1.1
+++ developersguide.xml 28 Oct 2012 15:21:17 -0000 1.2
@@ -1,10 +1,10 @@
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/Python/developersguide.xml,v 1.1 2010/12/13 11:17:44 nimiux Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/Python/developersguide.xml,v 1.2 2012/10/28 15:21:17 swift Exp $ -->
-<guide link="/proj/en/Python/developersguide.xml" lang="es">
+<guide lang="es">
<title>Guía Gentoo para desarrolladores Python</title>
<author title="Autor">
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2012-10-28 15:32 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-12-13 11:17 [gentoo-commits] gentoo commit in xml/htdocs/proj/es/Python: developersguide.xml JosA MarAa Alonso (nimiux)
-- strict thread matches above, loose matches on Subject: below --
2012-10-28 15:21 Sven Vermeulen (swift)
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox