@node Contribuir
@chapter Contribuir

Este proyecto es un esfuerzo colaborativo, y ¡necesitamos su ayuda para que
crezca! Por favor, contacte con nosotras en @email{guix-devel@@gnu.org} y en
@code{#guix} en la red IRC Freenode. Estamos abiertas a ideas, informes de
errores, parches y cualquier cosa que pueda ser de ayuda para el
proyecto. Especialmente se agradece ayuda en empaquetamiento
(@pxref{Guías de empaquetamiento}).

@cindex código de conducta, de contribuidoras
@cindex acuerdo de contribución
Queremos proporcionar un entorno cálido, amistoso y libre de acoso, para que
cualquiera pueda contribuir al máximo de sus capacidades. Para este fin
nuestro proyecto usa un ``Acuerdo de Contribución'', que fue adaptado de
@url{http://contributor-coventant.org}. Se puede encontrar una versión local
en el fichero @file{CODE-OF-CONDUCT} del árbol de fuentes.

Las contribuidoras no están obligadas a usar su nombre legal en los parches
ni en la comunicación on-line; pueden usar cualquier nombre o seudónimo de
su elección.

@menu
* Construcción desde Git::  Lo último y mejor.
* Ejecución de Guix antes de estar instalado::  Trucos de hacker.
* La configuración perfecta::  Las herramientas adecuadas.
* Guías de empaquetamiento::  Crecimiento de la distribución.
* Estilo de codificación::  Higiene de la contribuidora.
* Envío de parches::        Comparta su trabajo.
@end menu

@node Construcción desde Git
@section Construcción desde Git

Si quiere picar en el mismo Guix se recomienda usar la última versión del
repositorio Git:

@example
git clone https://git.savannah.gnu.org/git/guix.git
@end example

Cuando se compila Guix de una copia de trabajo local (checkout), se
requieren los siguientes paquetes, además de los mencionados en las
instrucciones de instalación (@pxref{Requisitos}).

@itemize
@item @url{http://gnu.org/software/autoconf/, GNU Autoconf};
@item @url{http://gnu.org/software/automake/, GNU Automake};
@item @url{http://gnu.org/software/gettext/, GNU Gettext};
@item @url{http://gnu.org/software/texinfo/, GNU Texinfo};
@item @url{http://www.graphviz.org/, Graphviz};
@item @url{http://www.gnu.org/software/help2man/, GNU Help2man (opcional)}.
@end itemize

El modo más fácil de preparar un entorno de desarrollo para Guix es, por
supuesto, ¡usando Guix! Las siguientes órdenes inician un nuevo intérprete
donde todas las dependencias y las variables de entorno apropiadas están
listas para picar código en Guix:

@example
guix environment guix
@end example

@xref{Invocación de guix environment}, para más información sobre esa orden. Se
pueden añadir dependencias adicionales con la opción @option{--ad-hoc}:

@example
guix environment guix --ad-hoc help2man git strace
@end example

Ejecute @command{./bootstrap} para generar la infraestructura del sistema de
construcción usando Autoconf y Automake. Si obtiene un error como este:

@example
configure.ac:46: error: possibly undefined macro: PKG_CHECK_MODULES
@end example

@noindent
probablemente significa que Autoconf no pudo encontrar el fichero pkg.m4,
que proporciona pkg-config. Asegurese de que @file{pkg.m4} está
disponible. Lo mismo aplica para el conjunto de macros @file{guile.m4} que
proporciona Guile. Por ejemplo, si ha instalado Automake en
@file{/usr/local}, no va a buscar ficheros @file{.m4} en
@file{/usr/share}. En ese caso tiene que ejecutar la siguiente orden:

@example
export ACLOCAL_PATH=/usr/share/aclocal
@end example

@xref{Macro Search Path,,, automake, The GNU Automake Manual} para más
información.

Entonces, ejecute @command{./configure} como siempre. Asegurese de pasar
@code{--localstatedir=@var{directorio}}, donde @var{directorio} es el valor
de @code{localstatedir} usado por su instalación actual (@pxref{El almacén},
para información sobre esto).

Finalmente, tiene que ejecutar @code{make check} para iniciar las pruebas
(@pxref{Ejecución de la batería de pruebas}). Si algo falla, eche un vistazo a las
instrucciones de instalación (@pxref{Instalación}) o envíe un mensaje---en
Inglés---a la @email{guix-devel@@gnu.org, lista de correo}.


@node Ejecución de Guix antes de estar instalado
@section Ejecución de Guix antes de estar instalado

Para mantener un entorno de trabajo estable, encontrará útil probar los
cambios hechos en su copia de trabajo local sin instalarlos realmente. De
esa manera, puede distinguir entre su sombrero de ``usuaria final'' y el
traje de ``harapos''.

Para dicho fin, todas las herramientas de línea de órdenes pueden ser usadas
incluso si no ha ejecutado @code{make install}. Para hacerlo, primero
necesita tener un entorno con todas las dependencias disponibles
(@pxref{Construcción desde Git}), y entonces añada al inicio de cada orden
@command{./pre-inst-env} (el guión @file{pre-inst-env} se encuentra en la
raíz del árbol de compilación de Guix, como en@footnote{La opción
@option{-E} a @command{sudo} asegura que @code{GUILE_LOAD_PATH} contiene la
información correcta para que @command{guix-daemon} y las herramientas que
usa puedan encontrar los módulos Guile que necesitan.}:

@example
$ sudo -E ./pre-inst-env guix-daemon --build-users-group=guixbuild
$ ./pre-inst-env guix build hello
@end example

@noindent
De manera similar, para una sesión de Guile que use los módulos Guix:

@example
$ ./pre-inst-env guile -c '(use-modules (guix utils)) (pk (%current-system))'

;;; ("x86_64-linux")
@end example

@noindent
@cindex REPL
@cindex entorno interactivo
@dots{} y para un entorno interactivo (REPL) (@pxref{Using Guile
Interactively,,, guile, Guile Reference Manual}):

@example
$ ./pre-inst-env guile
scheme@@(guile-user)> ,use(guix)
scheme@@(guile-user)> ,use(gnu)
scheme@@(guile-user)> (define serpientes
                       (fold-packages
                         (lambda (paquete lst)
                           (if (string-prefix? "python"
                                               (package-name paquete))
                               (cons paquete lst)
                               lst))
                         '()))
scheme@@(guile-user)> (length serpientes)
$1 = 361
@end example

El guión @command{pre-inst-env} fija todas las variables de entorno
necesarias para permitir esto, incluyendo @env{PATH} y
@env{GUILE_LOAD_PATH}.

Fíjese que la orden @command{./pre-inst-env guix pull} @emph{no} actualiza
el árbol de fuentes local; simplemente actualiza el enlace
@file{~/.config/guix/latest} (@pxref{Invocación de guix pull}). Ejecute
@command{git pull} si quiere actualizar su árbol de fuentes local.


@node La configuración perfecta
@section La configuración perfecta

La configuración perfecta para hackear en Guix es básicamente la
configuración perfecta para hacerlo en Guile (@pxref{Using Guile in Emacs,,,
guile, Guile Reference Manual}). Primero, necesita más que un editor,
necesita @url{http://www.gnu.org/software/emacs, Emacs}, empoderado por el
maravilloso @url{http://nongnu.org/geiser, Geiser}. Para configurarlo,
ejecute:

@example
guix package -i emacs guile emacs-geiser
@end example

Geiser permite desarrollo incremental e interactivo dentro de Emacs:
compilación y evaluación de código dentro de los buffers, acceso a
documentación en línea (docstrings), completado dependiente del contexto,
@kbd{M-.} para saltar a la definición de un objeto, una consola interactiva
(REPL) para probar su código, y más (@pxref{Introducción,,, geiser, Geiser
User Manual}). Para desarrollar Guix adecuadamente, asegúrese de aumentar la
ruta de carga de Guile (load-path) para que encuentre los ficheros fuente de
su copia de trabajo:

@lisp
;; @r{Suponiendo que la copia de trabajo de Guix está en ~/src/guix.}
(with-eval-after-load 'geiser-guile
  (add-to-list 'geiser-guile-load-path "~/src/guix"))
@end lisp

Para realmente editar el código, Emacs tiene un modo limpio para
Scheme. Pero además de eso, no debe perderse
@url{http://www.emacswiki.org/emacs/ParEdit, Paredit}. Provee de facilidades
para operar directamente en el árbol sintáctico como elevar una expresión S
o recubrirla, embeber o expulsar la siguiente expresión S, etc.

@cindex fragmentos de código
@cindex plantillas
@cindex reducir la verborrea
También proporcionamos plantillas para los mensajes de revisión de git
comunes y definiciones de paquetes en el directorio
@file{etc/snippets}. Estas plantillas pueden ser usadas con
@url{http://joaotavora.github.io/yasnippet, YASnippet} para expandir
mnemotécnicos a fragmentos interactivos de texto. Puedes querer añadir el
directorio de fragmentos a la variable @var{yas-snippet-dirs} en Emacs.

@lisp
;; @r{Suponiendo que la copia de trabajo de Guix está en ~/src/guix.}
(with-eval-after-load 'yasnippet
  (add-to-list 'yas-snippet-dirs "~/src/guix/etc/snippets"))
@end lisp

Los fragmentos de mensajes de la revisión dependen de
@url{https://magit.vc/, Magit} para mostrar los ficheros preparados. En la
edición del mensaje de la revisión teclee @code{add} seguido de @kbd{TAB}
(el tabulador) para insertar la plantilla del mensaje de la revisión de
adición de un paquete; teclee @code{update} seguido de @kbd{TAB} para
insertar una plantilla de actualización de un paquete; teclee @code{https}
seguido de @kbd{TAB} para insertar una plantilla para cambiar la URI de la
página de un paquete a HTTPS.

El fragmento principal para @code{scheme-mode} es activado al teclear
@code{package...} seguido de @kbd{TAB}. Este fragmento también inserta el
lanzador @code{origin...} que puede ser expandido de nuevo. El fragmento
@code{origin} puede a su vez insertar otros identificadores de lanzado
terminando en @code{...}, que pueden ser expandidos de nuevo.


@node Guías de empaquetamiento
@section Guías de empaquetamiento

@cindex paquetes, creación
La distribución GNU es reciente y puede no disponer de alguno de sus
paquetes favoritos. Esta sección describe cómo puede ayudar a hacer crecer
la distribución.

Los paquetes de software libre habitualmente se distribuyen en forma de
@dfn{archivadores de código fuente}---típicamente ficheros @file{tar.gz} que
contienen todos los ficheros fuente. Añadir un paquete a la distribución
significa esencialmente dos cosas: añadir una @dfn{receta} que describe cómo
construir el paquete, la que incluye una lista de otros paquetes necesarios
para la construcción, y añadir @dfn{metadatos del paquete} junto a dicha
receta, como la descripción y la información de licencias.

En Guix toda esta información está contenida en @dfn{definiciones de
paquete}. Las definiciones de paquete proporcionan una vista de alto nivel
del paquete. Son escritas usando la sintaxis del lenguaje de programación
Scheme; de hecho, definimos una variable por cada paquete enlazada a su
definición y exportamos esa variable desde un módulo (@pxref{Módulos de paquetes}). No obstante, un conocimiento profundo de Scheme @emph{no} es un
pre-requisito para la creación de paquetes. Para más información obre las
definiciones de paquetes, @pxref{Definición de paquetes}.

Una vez que una definición de paquete está en su lugar, almacenada en un
fichero del árbol de fuentes de Guix, puede probarse usando la orden
@command{guix build} (@pxref{Invocación de guix build}). Por ejemplo, asumiendo
que el nuevo paquete se llama @code{gnuevo}, puede ejecutar esta orden desde
el árbol de construcción de Guix (@pxref{Ejecución de Guix antes de estar instalado}):

@example
./pre-inst-env guix build gnuevo --keep-failed
@end example

El uso de @code{--keep-failed} facilita la depuración de errores de
construcción ya que proporciona acceso al árbol de la construcción
fallida. Otra opción útil de línea de órdenes para la depuración es
@code{--log-file}, para acceder al log de construcción.

Si el paquete resulta desconocido para la orden @command{guix}, puede ser
que el fichero fuente contenga un error de sintaxis, o no tenga una cláusula
@code{define-public} para exportar la variable del paquete. Para encontrar
el problema puede cargar el módulo desde Guile para obtener más información
sobre el error real:

@example
./pre-inst-env guile -c '(use-modules (gnu packages gnuevo))'
@end example

Una vez que se construya correctamente su paquete, por favor, envíenos un
parche (@pxref{Envío de parches}). En cualquier caso, si necesita ayuda
también estaremos felices de ayudarle. Una vez el parche se haya incorporado
al repositorio de Guix, el nuevo paquete se construye automáticamente en las
plataformas disponibles por @url{http://hydra.gnu.org/jobset/gnu/master,
nuestro sistema de integración continua}.

@cindex servidor de sustituciones
Las usuarias pueden obtener la nueva definición de paquete ejecutando
simplemente @command{guix pull} (@pxref{Invocación de guix pull}). Cuando
@code{@value{SUBSTITUTE-SERVER}} ha terminado de construir el paquete, la
instalación del paquete descarga automáticamente los binarios desde allí
(@pxref{Sustituciones}). El único lugar donde la intervención humana es
necesaria es en la revisión y aplicación del parche.


@menu
* Libertad del software::    Qué puede entrar en la distribución.
* Nombrado de paquetes::     ¿Qué hay en un nombre?
* Versiones numéricas::     Cuando el nombre no es suficiente.
* Sinopsis y descripciones::  Ayudar a las usuarias a encontrar el paquete 
                                adecuado.
* Módulos Python::          Un toque de comedia británica.
* Módulos Perl::            Pequeñas perlas.
* Paquetes Java::            La parada del café.
* Tipografías::             Amor por las letras.
@end menu

@node Libertad del software
@subsection Libertad del software

@c ===========================================================================
@c
@c This file was generated with po4a. Translate the source file.
@c
@c ===========================================================================
@c Adapted from http://www.gnu.org/philosophy/philosophy.html.
@cindex software libre
El sistema operativo GNU se ha desarrollado para que las usuarias puedan
ejercitar su libertad de computación. GNU es @dfn{software libre}, lo que
significa ue las usuarias tienen las
@url{http://www.gnu.org/philosophy/free-sw.html,cuatro libertades
esenciales}: para ejecutar el programa, para estudiar y modificar el
programa en la forma de código fuente, para redistribuir copias exactas y
para distribuir versiones modificadas. Los paquetes encontrados en la
distribución GNU proporcionan únicamente software que permite estas cuatro
libertades.

Además, la distribución GNU sigue las
@url{http://www.gnu.org/distros/free-system-distribution-guidelines.html,directrices
de distribución de software libre}. Entre otras cosas, estas directrices
rechazan firmware no-libre, recomendaciones de software no-libre y el
tratamiento de formas de tratar con marcas registradas y patentes.

Algunos paquetes originales, que serían de otra manera software libre,
contienen un subconjunto pequeño y opcional que viola estas directrices, por
ejemplo debido a que ese subconjunto sea en sí código no-libre. Cuando esto
sucede, las partes indeseadas son eliminadas con parches o fragmentos de
código en la forma @code{origin} del paquete (@pxref{Definición de paquetes}). De
este modo, @code{guix build --source} devuelve las fuentes ``liberadas'' en
vez de la versión original de las fuentes.


@node Nombrado de paquetes
@subsection Nombrado de paquetes

@cindex nombre de paquete
Un paquete tiene realmente dos nombres asociados con él: Primero, el nombre
de la @emph{variable Scheme} asociada, que aparece después de
@code{define-public}. A través de este nombre, el paquete está disponible en
código Scheme, por ejemplo como entrada de otro paquete. Segundo, la cadena
en el campo @code{name} de la definición de paquete. Este nombre se usa por
las órdenes de gestión de paquetes como @command{guix package} y
@command{guix build}.

Ambos normalmente son iguales y corresponden a la conversión a minúsculas
del nombre de proyecto elegido por sus creadoras, con los guiones bajos
sustituidos por guiones. Por ejemplo, GNUnet está disponible como
@code{gnunet}, y SDL_net como @code{sdl-net}.

No añadimos prefijos @code{lib} para paquetes de bibliotecas, a menos que
sean parte del nombre oficial del proyecto. Pero vea @ref{Módulos Python} y
@ref{Módulos Perl} para reglas especiales que conciernen a los módulos de
los lenguajes Python y Perl.

Los nombres de paquetes de tipografías se manejan de forma diferente,
@pxref{Tipografías}.


@node Versiones numéricas
@subsection Versiones numéricas

@cindex versión de paquete
Normalmente empaquetamos únicamente la última versión de un proyecto dado de
software libre. Pero a veces, por ejemplo para versiones de bibliotecas
incompatibles, se necesitan dos (o más) versiones del mismo paquete. Estas
necesitan nombres diferentes para las variables Scheme. Usamos el nombre
como se define en @ref{Nombrado de paquetes} para la versión más reciente; las
versiones previas usan el mismo nombre, añadiendo un @code{-} y el prefijo
menor del número de versión que permite distinguir las dos versiones.

El nombre dentro de la definición de paquete es el mismo para todas las
versiones de un paquete y no contiene ningún número de versión.

Por ejemplo, las versiones 2.24.20 y 3.9.12 de GTK+ pueden empaquetarse como
sigue:

@example
(define-public gtk+
  (package
    (name "gtk+")
    (version "3.9.12")
    ...))
(define-public gtk+-2
  (package
    (name "gtk+")
    (version "2.24.20")
    ...))
@end example
Si también deseásemos GTK+3.8.2, se empaquetaría como
@example
(define-public gtk+-3.8
  (package
    (name "gtk+")
    (version "3.8.2")
    ...))
@end example

@c See <https://lists.gnu.org/archive/html/guix-devel/2016-01/msg00425.html>,
@c for a discussion of what follows.
@cindex número de versión, para revisiones de VCS
De manera ocasional, empaquetamos instantáneas del sistema de control de
versiones (VCS) de las desarrolladoras originales en vez de publicaciones
formales. Esto debería permanecer como algo excepcional, ya que son las
desarrolladoras originales quienes deben clarificar cual es la entrega
estable. No obstante, a veces es necesario. Por tanto, ¿qué deberíamos poner
en el campo @code{version}?

Claramente, tenemos que hacer visible el identificador de la revisión en el
VCS en la cadena de versión, pero tamién debemos asegurarnos que la cadena
de versión incrementa monotónicamente de manera que @command{guix package
--upgrade} pueda determinar qué versión es más moderna. Ya que los
identificadores de revisión, notablemente en Git, no incrementan
monotónicamente, añadimos un número de revisión que se incrementa cada vez
que actualizamos a una nueva instantánea. La versión que resulta debería ser
así:

@example
2.0.11-3.cabba9e
  ^    ^    ^
  |    |    `-- ID de revisión original
  |    |
  |    `--- revisión del paquete Guix
  |
última versión de publicación
@end example

Es una buena idea recortar los identificadores de revisión en el campo
@code{version} a, digamos, 7 dígitos. Esto evita una molestia estética
(asumiendo que la estética tiene importancia aquí) así como problemas
relacionados con los límites del sistema operativo como la longitud máxima
de una cadena de ejecución #! (127 bytes en el núcleo Linux). Es mejor usar
el identificador de revisión completo en @code{origin}, no obstante, para
evitar ambigüedades. Una definición típica de paquete sería así:

@example
(define mi-paquete
  (let ((commit "c3f29bc928d5900971f65965feaae59e1272a3f7")
        (revision "1"))          ;Revisión Guix del paquete
    (package
      (version (git-version "0.9" revision commit))
      (source (origin
                (method git-fetch)
                (uri (git-reference
                      (url "git://example.org/mi-paquete.git")
                      (commit commit)))
                (sha256 (base32 "1mbikn@dots{}"))
                (file-name (git-file-name name version))))
      ;; @dots{}
      )))
@end example

@node Sinopsis y descripciones
@subsection Sinopsis y descripciones

@cindex descripción de paquete
@cindex sinopsis de paquete
Como hemos visto previamente, cada paquete en GNU@tie{}Guix incluye una
sinopsis y una descripción (@pxref{Definición de paquetes}). Las sinopsis y
descripciones son importantes: son en lo que @command{guix package --search}
busca, y una pieza crucial de información para ayudar a las usuarias a
determinar si un paquete dado cubre sus necesidades. Consecuentemente, las
empaquetadoras deben prestar atención a qué se incluye en ellas.

Las sinopsis deben empezar con mayúscula y no deben terminar con punto. No
deben empezar con un artículo que habitualmente no aporta nada; por ejemplo,
se prefiere ``Herramienta para chiribizar'' sobre ``Una herramienta que
chiribiza ficheros''. La sinopsis debe decir qué es el paquete---por
ejemplo, ``Utilidades básicas GNU (ficheros, texto, shell)''---o para qué se
usa---por ejemplo, la sinopsis de GNU@tie{}grep es ``Imprime líneas que
aceptadas por un patrón''.

Tenga en cuenta que las sinopsis deben tener un claro significado para una
audiencia muy amplia. Por ejemplo, ``Manipula la alineación en el formato
SAM'' puede tener sentido para una investigadora de bioinformática con
experiencia, pero puede ser de poca ayuda o incluso llevar a confusión a una
audiencia no-especializada. Es una buena idea proporcionar una sinopsis que
da una idea del dominio de aplicación del paquete. En ese ejemplo, esto
podría ser algo como ``Manipula la alineación de secuencias de
nucleótidos'', lo que esperablemente proporciona a la usuaria una mejor idea
sobre si esto es lo que está buscando.

Las descripciones deben tener entre cinco y diez líneas. Use frases
completas, y evite usar acrónimos sin introducirlos previamente. Por favor
evite frases comerciales como ``líder mundial'', ``de potencia industrial''
y ``siguiente generación'', y evite superlativos como ``el más
avanzado''---no son útiles para las usuarias que buscan un paquete e incluso
pueden sonar sospechosas. En vez de eso, intente ceñirse a los hechos,
mencionando casos de uso y características.

@cindex marcado Texinfo, en descripciones de paquetes
Las descripciones pueden incluir marcado Texinfo, lo que es útil para
introducir ornamentos como @code{@@code} o @code{@@dfn}, listas de puntos o
enlaces (@pxref{Overview,,, texinfo, GNU Texinfo}). Por consiguiente, debe
ser cuidadosa cuando use algunos caracteres, por ejemplo @samp{@@} y llaves,
que son los caracteres especiales básicos en Texinfo (@pxref{Special
Characters,,, texinfo, GNU Texinfo}). Las interfaces de usuaria como
@command{guix package --show} se encargan de su correcta visualización.

Las sinopsis y descripciones son traducidas por voluntarias
@uref{http://translationproject.org/domain/guix-packages.html, en
Translation Project} para que todas las usuarias posibles puedan leerlas en
su lengua nativa. Las interfaces de usuaria las buscan y las muestran en el
idioma especificado por la localización actual.

Para permitir a @command{xgettext} extraerlas como cadenas traducibles, las
sinopsis y descripciones @emph{deben ser cadenas literales}. Esto significa
que no puede usar @code{string-append} o @code{format} para construir estas
cadenas:

@lisp
(package
  ;; @dots{}
  (synopsis "Esto es traducible")
  (description (string-append "Esto " "*no*" " es traducible.")))
@end lisp

La traducción requiere mucho trabajo, por lo que, como empaquetadora, le
rogamos que ponga incluso más atención a sus sinopsis y descripciones ya que
cada cambio puede suponer trabajo adicional para las traductoras. Para
ayudarlas, es posible hacer recomendaciones o instrucciones insertando
comentarios especiales como este (@pxref{xgettext Invocation,,, gettext, GNU
Gettext}):

@example
;; TRANSLATORS: "X11 resize-and-rotate" should not be translated.
(description "ARandR is designed to provide a simple visual front end
for the X11 resize-and-rotate (RandR) extension. @dots{}")
@end example


@node Módulos Python
@subsection Módulos Python

@cindex python
Actualmente empaquetamos Python 2 y Python 3, bajo los nombres de variable
Scheme @code{python-2} y @code{python} como se explica en @ref{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 @code{python}.

Algunos módulos son compatibles únicamente con una versión de Python, otros
con ambas. Si el paquete Foo compila sólo con Python 3, lo llamamos
@code{python-foo}; si compila sólo con Python 2, lo llamamos
@code{python2-foo}. Si es compatible con ambas versiones, creamos dos
paquetes con los nombres correspondientes.

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

@subsubsection Especificación de dependencias
@cindex entradas, para paquetes Python

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

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

@itemize

@item
Actualmente empaquetamos con @code{setuptools} y @code{pip} instalados como
Python 3.4 tiene por defecto. Por tanto no necesita especificar ninguno de
ellos como entrada. @command{guix lint} le avisará si lo hace.

@item
Las dependencias Python requeridas en tiempo de ejecución van en
@code{propagated-inputs}. Típicamente están definidas con la palabra clave
@code{install_requires} en @file{setup.py}, o en el fichero
@file{requirements.txt}.

@item
Los paquetes Python requeridos únicamente durante la construcción---por
ejemplo, aquellos listados con la palabra clave @code{setup_requires} en
@file{setup.py}---o únicamente para pruebas---por ejemplo, aquellos en
@code{tests_require}---van en @code{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 @code{pytest}, @code{mock} y
@code{nose}. Por supuesto, si alguno de estos paquetes también se necesita
en tiempo de ejecución, necesita ir en @code{propagated-inputs}.

@item
Todo lo que no caiga en las categorías anteriores va a @code{inputs}, por
ejemplo programas o bibliotecas C requeridas para construir los paquetes
Python que contienen extensiones C.

@item
Si un paquete Python tiene dependencias opcionales (@code{extras_require}),
queda en su mano decidir si las añade o no, en base a la relación
utilidad/sobrecarga (@pxref{Envío de parches, @command{guix size}}).

@end itemize


@node Módulos Perl
@subsection Módulos Perl

@cindex perl
Los programas ejecutables Perl se nombran como cualquier otro paquete,
mediante el uso del nombre oficial en minúsculas. Para paquetes Perl que
contienen una única clase, usamos el nombre en minúsculas de la clase,
substituyendo todas las ocurrencias de @code{::} por guiones y agregando el
prefijo @code{perl-}. Por tanto la clase @code{XML::Parser} se convierte en
@code{perl-xml-parser}. Los módulos que contienen varias clases mantienen su
nombre oficial en minúsculas y también se agrega @code{perl-} al
inicio. Dichos módulos tienden a tener la palabra @code{perl} en alguna
parte de su nombre, la cual se elimina en favor del prefijo. Por ejemplo,
@code{libwww-perl} se convierte en @code{perl-libwww}.


@node Paquetes Java
@subsection Paquetes Java

@cindex java
Los programas Java ejecutables se nombran como cualquier otro paquete,
mediante el uso del nombre oficial en minúsculas.

Para evitar confusión y colisiones de nombres con otros lenguajes de
programación, es deseable que el nombre del paquete para un paquete Java
contenga el prefijo @code{java-}. Si el proyecto ya tiene la palabra
@code{java}, eliminamos esta; por ejemplo, el paquete @code{ngsjaga} se
empaqueta bajo el nombre @code{java-ngs}.

Para los paquetes Java que contienen una clase única o una jerarquía
pequeña, usamos el nombre de clase en minúsculas, substituyendo todas las
ocurrencias de @code{.} por guiones y agregando el prefijo @code{java-}. Por
tanto la clase @code{apache.commons.cli} se convierte en el paquete
@code{java-apache-commons-cli}.


@node Tipografías
@subsection Tipografías

@cindex tipografías
Para tipografías que no se instalan generalmente por una usuaria para
propósitos tipográficos, o que se distribuyen como parte de un paquete de
software más grande, seguimos las reglas generales de empaquetamiento de
software; por ejemplo, esto aplica a las tipografías distribuidas como parte
del sistema X.Org o las tipografías que son parte de TeX Live.

Para facilitar a las usuarias la búsqueda de tipografías, los nombres para
otros paquetes que contienen únicamente tipografías se construyen como
sigue, independientemente del nombre de paquete oficial.

El nombre de un paquete que contiene únicamente una familia tipográfica
comienza con @code{font-}; seguido por el nombre de la tipografía y un guión
si la tipografía es conocida, y el nombre de la familia tipográfica, donde
los espacios se sustituyen por guiones (y como es habitual, todas las letras
mayúsculas se transforman a minúsculas). Por ejemplo, la familia de
tipografías Gentium de SIL se empaqueta bajo el nombre de
@code{font-sil-gentium}.

Para un paquete que contenga varias familias tipográficas, el nombre de la
colección se usa en vez del nombre de la familia tipográfica. Por ejemplo,
las tipografías Liberation consisten en tres familias: Liberation Sans,
Liberation Serif y Liberation Mono. Estas se podrían empaquetar por separado
bajo los nombres @code{font-liberation-sans}, etcétera; pero como se
distribuyen de forma conjunta bajo un nombre común, preferimos empaquetarlas
conjuntamente como @code{font-liberation}.

En el caso de que varios formatos de la misma familia o colección
tipográfica se empaqueten de forma separada, una forma corta del formato,
precedida por un guión, se añade al nombre del paquete. Usamos @code{-ttf}
para tipografías TrueType, @code{-otf} para tipografías OpenType y
@code{-type1} para tipografías Tipo 1 PostScript.


@node Estilo de codificación
@section Estilo de codificación

En general nuestro código sigue los Estándares de codificación GNU
(@pxref{Top,,, standards, GNU Coding Standards}). No obstante, no dicen
mucho de Scheme, así que aquí están algunas reglas adicionales.

@menu
* Paradigma de programación::  Cómo componer sus elementos.
* Módulos::                 ¿Dónde almacenar su código?
* Tipos de datos y reconocimiento de patrones::  Implementación de 
                                                   estructuras de datos.
* Formato del código::      Convenciones de escritura.
@end menu

@node Paradigma de programación
@subsection Paradigma de programación

El código scheme en Guix está escrito en un estilo puramente funcional. Una
excepción es el código que incluye entrada/salida, y procedimientos que
implementan conceptos de bajo nivel, como el procedimiento @code{memoize}.

@node Módulos
@subsection Módulos

Los módulos Guile que están destinados a ser usados en el lado del
constructor deben encontrarse en el espacio de nombres @code{(guix build
@dots{})}. No deben hacer referencia a otros módulos Guix o GNU. No
obstante, no hay problema en usar un módulo del lado del constructor en un
módulo ``del lado del cliente''.

Los módulos que tratan con el sistema GNU más amplio deben estar en el
espacio de nombres @code{(gnu @dots{})} en vez de en @code{(guix @dots{})}.

@node Tipos de datos y reconocimiento de patrones
@subsection Tipos de datos y reconocimiento de patrones

La tendencia en el Lisp clásico es usar listas para representar todo, y
recorrerlas ``a mano'' usando @code{car}, @code{cdr}, @code{cadr} y
compañía. Hay varios problemas con este estilo, notablemente el hecho de que
es difícil de leer, propenso a errores y una carga para informes adecuados
de errores de tipado.

El código de Guix debe definir tipos de datos apropiados (por ejemplo,
mediante el uso @code{define-record-type*}) en vez de abusar de las
listas. Además debe usarse el reconocimiento de patrones, vía el módulo de
Guile @code{(ice-9 match)}, especialmente cuando se analizan listas.

@node Formato del código
@subsection Formato del código

@cindex dar formato al código
@cindex estilo de codificación
Cuando escribimos código Scheme, seguimos la sabiduría común entre las
programadoras Scheme. En general, seguimos las
@url{http://mumble.net/~campbell/scheme/style.txt, Reglas de estilo Lisp de
Riastradh}. Este documento resulta que también describe las convenciones más
usadas en el código Guile. Está lleno de ideas y bien escrito, así que
recomendamos encarecidamente su lectura.

Algunas formas especiales introducidas en Guix, como el macro
@code{substitute*} tienen reglas de indentación especiales. Estas están
definidas en el fichero @file{.dir-locals.el}, el cual Emacs usa
automáticamente. Fíjese que además Emacs-Guix proporciona el modo
@code{guix-devel-mode} que indenta y resalta adecuadamente el código de Guix
(@pxref{Desarrollo,,, emacs-guix, The Emacs-Guix Reference Manual}).

@cindex indentación, de código
@cindex formato, de código
Si no usa Emacs, por favor asegúrese de que su editor conoce esas
reglas. Para indentar automáticamente una definición de paquete también
puede ejecutar:

@example
./etc/indent-code.el gnu/packages/@var{fichero}.scm @var{paquete}
@end example

@noindent
Esto indenta automáticamente la definición de @var{paquete} en
@file{gnu/packages/@var{fichero}.scm} ejecutando Emacs en modo de
procesamiento de lotes. Para indentar un fichero completo, omita el segundo
parámetro:

@example
./etc/indent-code.el gnu/services/@var{fichero}.scm
@end example

@cindex Vim, edición de código Scheme
Si está editando código con Vim, le recomendamos ejecutar @code{:set
autoindent} para que el código se indente automáticamente mientras
escribe. Adicionalmente,
@uref{https://www.vim.org/scripts/script.php?script_id=3998,
@code{paredit.vim}} puede ayudar a manejar todos estos paréntesis.

Requerimos que todos los procedimientos del nivel superior tengan una cadena
de documentación. Este requisito puede relajarse para procedimientos simples
privados en el espacio de nombres @code{(guix build @dots{})} no obstante.

Los procedimientos no deben tener más de cuatro parámetros posicionales. Use
parámetros con palabras clave para procedimientos que toman más de cuatro
parámetros.


@node Envío de parches
@section Envío de parches

El desarrollo se lleva a cabo usando el sistema de control de versiones
distribuido Git. Por lo tanto, no es estrictamente necesario el acceso al
repositorio. Son bienvenidas las contribuciones en forma de parches como los
producidos por @code{git format-patch} enviadas a la lista de correo
@email{guix-patches@@gnu.org}.

Esta lista de correo está respaldada por una instancia de Debbugs accesible
en @uref{https://bugs.gnu.org/guix-patches}, la cual nos permite mantener el
seguimiento de los envíos. A cada mensaje enviado a esa lista de correo se
le asigna un número de seguimiento; la gente puede realizar aportaciones
sobre el tema mediante el envío de correos electrónicos a
@code{@var{NNN}@@debbugs.gnu.org}, donde @var{NNN} es el número de
seguimiento (@pxref{Envío de una serie de parches}).

Le rogamos que escriba los mensajes de revisiones en formato ChangeLog
(@pxref{Change Logs,,, standards, GNU Coding Standards}); puede comprobar la
historia de revisiones en busca de ejemplos.

Antes de enviar un parche que añade o modifica una definición de un paquete,
por favor recorra esta lista de comprobaciones:

@enumerate
@item
Si las autoras del paquete software proporcionan una firma criptográfica
para el archivo de la versión, haga un esfuerzo para verificar la
autenticidad del archivo. Para un fichero de firma GPG separado esto puede
hacerse con la orden @code{gpg --verify}.

@item
Dedique algún tiempo a proporcionar una sinopsis y descripción adecuadas
para el paquete. @xref{Sinopsis y descripciones}, para algunas directrices.

@item
Ejecute @code{guix lint @var{paquete}}, donde @var{paquete} es el nombre del
paquete nuevo o modificado, y corrija cualquier error del que informe
(@pxref{Invocación de guix lint}).

@item
Asegurese de que el paquete compile en su plataforma, usando @code{guix
build @var{package}}.

@item
También le recomendamos que pruebe a construir el paquete en otras
plataformas disponibles. Como puede no disponer de acceso a dichas
plataformas hardware físicamente, le recomendamos el uso de
@code{qemu-binfmt-service-type} para emularlas. Para activarlo, añada el
siguiente servicio a la lista de servicios en su configuración
@code{operating-system}:

@example
(service qemu-binfmt-service-type
 (qemu-binfmt-configuration
   (platforms (lookup-qemu-platforms "arm" "aarch64" "mips64el"))
   (guix-support? #t)))
@end example

Una vez hecho esto, reconfigure su sistema.

Enotonces podrá construir paquetes para diferentes plataformas mediante la
opción @code{--system}. Por ejemplo, para la construcción del paquete
"hello" para las arquitecturas armhf, aarch64 o mips64 ejecutaría las
siguientes órdenes, respectivamente:
@example
guix build --system=armhf-linux --rounds=2 hello
guix build --system=aarch64-linux --rounds=2 hello
guix build --system=mips64el-linux --rounds=2 hello
@end example

@item
@cindex empaquetamientos
Asegurese de que el paquete no usa copias empaquetadas de software ya
disponible como paquetes separados.

A veces, paquetes incluyen copias embebidas del código fuente de sus
dependencias para conveniencia de las usuarias. No obstante, como
distribución, queremos asegurar que dichos paquetes efectivamente usan la
copia que ya tenemos en la distribución si hay ya una. Esto mejora el uso de
recursos (la dependencia es construida y almacenada una sola vez), y permite
a la distribución hacer cambios transversales como aplicar actualizaciones
de seguridad para un software dado en un único lugar y que afecte a todo el
sistema---algo que esas copias embebidas impiden.

@item
Eche un vistazo al perfil mostrado por @command{guix size} (@pxref{Invocación de guix size}). Esto le permitirá darse cuenta de referencias a otros paquetes
retenidas involuntariamente. También puede ayudar a determinar si se debe
dividir el paquete (@pxref{Paquetes con múltiples salidas}), y qué
dependencias opcionales deben usarse. En particular, evite añadir
@code{texlive} como una dependencia: debido a su tamaño extremo, use
@code{texlive-tiny} o @code{texlive-union}.

@item
Para cambios importantes, compruebe que los paquetes dependientes (si
aplica) no se ven afectados por el cambio; @code{guix refresh
--list-dependent @var{package}} le ayudará a hacerlo (@pxref{Invocación de guix refresh}).

@c See <https://lists.gnu.org/archive/html/guix-devel/2016-10/msg00933.html>.
@cindex estrategia de ramas
@cindex estrategia de planificación de reconstrucciones
En base al número de paquetes dependientes y, por tanto, del tamaño de la
reconstrucción inducida, los revisiones van a ramas separadas, según estas
líneas:

@table @asis
@item 300 paquetes dependientes o menos
rama @code{master} (cambios no disruptivos).

@item entre 300 y 1.200 paquetes dependientes
rama @code{staging} (cambios no disruptivos). Esta rama está pensada para
ser incorporada en @code{master} cada 3 semanas más o menos. Ramas temáticas
(por ejemplo, una actualización de la pila de GNOME) pueden ir en una rama
específica (digamos, @code{gnome-updates}).

@item más de 1.200 paquetes dependientes
rama @code{core-updates} (puede incluir cambios mayores y potencialmente
disruptivos). Esta rama está pensada para ser incluida en @code{master} cada
2,5 más o menos.
@end table

Todas estas ramas son @uref{https://hydra.gnu.org/project/gnu, seguidas por
nuestra granja de construcción} e incluidas en @code{master} una vez todo se
ha construido satisfactoriamente. Esto nos permite corregir errores antes de
que afecten a usuarias, y reducir la ventana durante la cual los binarios
preconstruidos no están disponibles.

@c TODO: It would be good with badges on the website that tracks these
@c branches.  Or maybe even a status page.
Generalmente, ramas distintas a @code{master} se consideran
@emph{congeladas} si ha habido una evaluación reciente, o hay una rama
@code{-next} correspondiente. Por favor, pregunte en la lista de correo o en
IRC si no está segura de dónde colocar un parche.

@item
@cindex determinismo, del proceso de construcción
@cindex construcciones reproducibles, comprobar
Compruebe si el proceso de construcción de un paquete es determinista. Esto
significa típicamente comprobar si una construcción independiente del
paquete ofrece exactamente el mismo resultado que usted obtuvo, bit a bit.

Una forma simple de hacerlo es construyendo el mismo paquete varias veces
seguidas en su máquina (@pxref{Invocación de guix build}):

@example
guix build --rounds=2 mi-paquete
@end example

Esto es suficiente una clase común de problemas de no-determinismo, como las
marcas de tiempo o salida generada aleatoriamente en el resultado de la
construcción.

Otra opción es el uso de @command{guix challenge} (@pxref{Invocación de guix challenge}). Puede ejecutarse una vez la revisión del paquete haya sido
publicada y construida por @code{@value{SUBSTITUTE-SERVER}} para comprobar
si obtuvo el mismo resultado que usted. Mejor aún: encuentre otra máquina
que pueda construirla y ejecute @command{guix publish}. Ya que la máquina
remota es probablemente diferente a la suya, puede encontrar problemas de
no-determinismo relacionados con el hardware---por ejemplo, el uso de un
conjunto de instrucciones extendido diferente---o con el núcleo del sistema
operativo---por ejemplo, dependencias en @code{uname} o ficheros
@file{/proc}.

@item
Cuando escriba documentación, por favor use construcciones neutrales de
género para referirse a la gente@footnote{NdT: En esta traducción se ha
optado por usar el femenino para referirse a @emph{personas}, ya que es el
género gramatical de dicha palabra. Aunque las construcciones impersonales
pueden adoptarse en la mayoría de casos, también pueden llegar a ser muy
artificiales en otros usos del castellano; en ocasiones son directamente
imposibles. Algunas construcciones que proponen la neutralidad de género
dificultan la lecura automática (-x), o bien dificultan la corrección
automática (-e), o bien aumentan significativamente la redundancia y reducen
del mismo modo la velocidad en la lectura (-as/os, -as y -os). No obstante,
la adopción del genero neutro heredado del latín, el que en castellano se ha
unido con el masculino, como construcción neutral de género se considera
inaceptable, ya que sería equivalente al ``it'' en inglés, nada más lejos de
la intención de las autoras originales del texto.}, como
@uref{https://en.wikipedia.org/wiki/Singular_they, singular ``they''@comma{}
``their''@comma{} ``them''} y demás.

@item
Compruebe que su parche contiene únicamente un conjunto relacionado de
cambios. Agrupando cambios sin relación dificulta y ralentiza la revisión.

Ejemplos de cambios sin relación incluyen la adición de varios paquetes, o
una actualización de un paquete junto a correcciones a ese paquete.

@item
Por favor, siga nuestras reglas de formato de código, posiblemente
ejecutando el guión @command{etc/indent-code.el} para que lo haga
automáticamente por usted (@pxref{Formato del código}).

@item
Cuando sea posible, use espejos en la URL de las fuentes (@pxref{Invocación de guix download}). Use URL fiables, no generadas. Por ejemplo, los archivos de
GitHub no son necesariamente idénticos de una generación a la siguiente, así
que en este caso es normalmente mejor clonar el repositorio. No use el campo
@command{name} en la URL: no es muy útil y si el nombre cambia, la URL
probablemente estará mal.

@end enumerate

Cuando publique un parche a la lista de correo, use @samp{[PATCH] @dots{}}
como el asunto. Puede usar su cliente de correo o la orden @command{git
send-email} (@pxref{Envío de una serie de parches}). Preferimos recibir los parches
en texto plano, ya sea en línea o como adjuntos MIME. Se le recomienda que
preste atención por si su cliente de correo cambia algo como los saltos de
línea o la indentación, lo que podría potencialmente romper los parches.

Cuando un error es resuelto, por favor cierre el hilo enviando un correo a
@email{@var{NNN}-done@@debbugs.gnu.org}.

@unnumberedsubsec Envío de una serie de parches
@anchor{Envío de una serie de parches}
@cindex series de parches
@cindex @code{git send-email}
@cindex @code{git-send-email}

@c Debbugs bug: https://debbugs.gnu.org/db/15/15361.html
Cuando envíe una serie de parches (por ejemplo, usando @code{git
send-email}), por favor mande primero un mensaje a
@email{guix-patches@@gnu.org}, y después mande los parches siguientes a
@email{@var{NNN}@@debbugs.gnu.org} para asegurarse de que se mantienen
juntos. Véase @uref{https://debbugs.gnu.org/Advanced.html, la documentación
de Debbugs} para más información.