This is guix.es.info, produced by makeinfo version 6.7 from
guix.es.texi.

Copyright © 2012-2022 Ludovic Courtès
Copyright © 2013, 2014, 2016 Andreas Enge
Copyright © 2013 Nikita Karetnikov
Copyright © 2014, 2015, 2016 Alex Kost
Copyright © 2015, 2016 Mathieu Lirzin
Copyright © 2014 Pierre-Antoine Rault
Copyright © 2015 Taylan Ulrich Bayırlı/Kammer
Copyright © 2015, 2016, 2017, 2019, 2020, 2021 Leo Famulari
Copyright © 2015, 2016, 2017, 2018, 2019, 2020, 2021, 2022 Ricardo
Wurmus
Copyright © 2016 Ben Woodcroft
Copyright © 2016, 2017, 2018, 2021 Chris Marusich
Copyright © 2016, 2017, 2018, 2019, 2020, 2021, 2022 Efraim Flashner
Copyright © 2016 John Darrington
Copyright © 2016, 2017 Nikita Gillmann
Copyright © 2016, 2017, 2018, 2019, 2020 Jan Nieuwenhuizen
Copyright © 2016, 2017, 2018, 2019, 2020, 2021 Julien Lepiller
Copyright © 2016 Alex ter Weele
Copyright © 2016, 2017, 2018, 2019, 2020, 2021 Christopher Baines
Copyright © 2017, 2018, 2019 Clément Lassieur
Copyright © 2017, 2018, 2020, 2021, 2022 Mathieu Othacehe
Copyright © 2017 Federico Beffa
Copyright © 2017, 2018 Carlo Zancanaro
Copyright © 2017 Thomas Danckaert
Copyright © 2017 humanitiesNerd
Copyright © 2017, 2021 Christine Lemmer-Webber
Copyright © 2017, 2018, 2019, 2020, 2021, 2022 Marius Bakke
Copyright © 2017, 2019, 2020, 2022 Hartmut Goebel
Copyright © 2017, 2019, 2020, 2021, 2022 Maxim Cournoyer
Copyright © 2017–2022 Tobias Geerinckx-Rice
Copyright © 2017 George Clemmer
Copyright © 2017 Andy Wingo
Copyright © 2017, 2018, 2019, 2020 Arun Isaac
Copyright © 2017 nee
Copyright © 2018 Rutger Helling
Copyright © 2018, 2021 Oleg Pykhalov
Copyright © 2018 Mike Gerwitz
Copyright © 2018 Pierre-Antoine Rouby
Copyright © 2018, 2019 Gábor Boskovits
Copyright © 2018, 2019, 2020, 2022 Florian Pelz
Copyright © 2018 Laura Lazzati
Copyright © 2018 Alex Vong
Copyright © 2019 Josh Holland
Copyright © 2019, 2020 Diego Nicola Barbato
Copyright © 2019 Ivan Petkov
Copyright © 2019 Jakob L. Kreuze
Copyright © 2019 Kyle Andrews
Copyright © 2019 Alex Griffin
Copyright © 2019, 2020, 2021, 2022 Guillaume Le Vaillant
Copyright © 2020 Liliana Marie Prikler
Copyright © 2019, 2020, 2021, 2022 Simon Tournier
Copyright © 2020 Wiktor Żelazny
Copyright © 2020 Damien Cassou
Copyright © 2020 Jakub Kądziołka
Copyright © 2020 Jack Hill
Copyright © 2020 Naga Malleswari
Copyright © 2020, 2021 Brice Waegeneire
Copyright © 2020 R Veera Kumar
Copyright © 2020, 2021 Pierre Langlois
Copyright © 2020 pinoaffe
Copyright © 2020 André Batista
Copyright © 2020, 2021 Alexandru-Sergiu Marton
Copyright © 2020 raingloom
Copyright © 2020 Daniel Brooks
Copyright © 2020 John Soo
Copyright © 2020 Jonathan Brielmaier
Copyright © 2020 Edgar Vincent
Copyright © 2021, 2022 Maxime Devos
Copyright © 2021 B. Wilson
Copyright © 2021 Xinglu Chen
Copyright © 2021 Raghav Gururajan
Copyright © 2021 Domagoj Stolfa
Copyright © 2021 Hui Lu
Copyright © 2021 pukkamustard
Copyright © 2021 Alice Brenon
Copyright © 2021, 2022 Josselin Poiret
Copyright © 2021 muradm
Copyright © 2021, 2022 Andrew Tropin
Copyright © 2021 Sarah Morgensen
Copyright © 2022 Remco van ’t Veer
Copyright © 2022 Aleksandr Vityazev
Copyright © 2022 Philip M^{c}Grath
Copyright © 2022 Karl Hallsby
Copyright © 2022 Justin Veilleux
Copyright © 2022 Reily Siegel
Copyright © 2022 Simon Streit
Copyright © 2022 (
Copyright © 2022 John Kehayias

   Se garantiza el permiso de copia, distribución y/o modificación de
este documento bajo los términos de la licencia de documentación libre
de GNU (GNU Free Documentation License), versión 1.3 o cualquier versión
posterior publicada por la Free Software Foundation; sin secciones
invariantes, sin textos de cubierta delantera ni trasera.  Una copia de
la licencia está incluida en la sección titulada “GNU Free Documentation
License”.
INFO-DIR-SECTION Administración del sistema
START-INFO-DIR-ENTRY
* Guix: (guix.es).           Gestión del software instalado y la
                               configuración del sistema.
* guix package: (guix.es)Invocación de guix package.  Instalación, borrado
                                                         y actualización de
                                                         paquetes.
* guix gc: (guix.es)Invocación de guix gc.  Recuperar espacio de disco sin
                                               usar.
* guix pull: (guix.es)Invocación de guix pull.  Actualización de la lista
                                                   disponible de paquetes.
* guix system: (guix.es)Invocación de guix system.  Gestión de la
                                                       configuración del
                                                       sistema operativo.
* guix deploy: (guix.es)Invocación de guix deploy.  Gestión de
                                                       configuraciones de
                                                       sistemas operativos en
                                                       máquinas remotas.
END-INFO-DIR-ENTRY

INFO-DIR-SECTION Desarrollo de software
START-INFO-DIR-ENTRY
* guix shell: (guix)Invoking guix shell.  Creating software environments.
* guix environment: (guix.es)Invocación de guix environment.  Construcción
                                                                 de entornos
                                                                 de desarrollo
                                                                 con Guix.
* guix build: (guix.es)Invocación de guix build.  Construcción de
                                                     paquetes.
* guix pack: (guix.es)Invocación de guix pack.  Creación de empaquetados
                                                   binarios.
END-INFO-DIR-ENTRY


File: guix.es.info,  Node: La cadena de herramientas de GCC,  Next: Invocación de guix git authenticate,  Prev: Invocación de guix pack,  Up: Desarrollo

8.4 La cadena de herramientas de GCC
====================================

Si necesita una cadena de herramientas de desarrollo completa para
compilar y enlazar código fuente C o C++, use el paquete
‘gcc-toolchain’.  Este paquete proporciona una cadena de herramientas
GCC para desarrollo C/C++, incluyendo el propio GCC, la biblioteca de C
GNU (cabeceras y binarios, más símbolos de depuración de la salida
‘debug’), Binutils y un recubrimiento del enlazador.

   El propósito del recubrimiento es inspeccionar las opciones ‘-L’ y
‘-l’ proporcionadas al enlazador, y los correspondientes parámetros
‘-rpath’, y llamar al enlazador real con este nuevo conjunto de
parámetros.  Puede instruir al recubrimiento para rechazar el enlace
contra bibliotecas que no se encuentren en el almacén proporcionando el
valor ‘no’ a la variable de entorno ‘GUIX_LD_WRAPPER_ALLOW_IMPURITIES’.

   El paquete ‘gfortran-toolchain’ proporciona una cadena de
herramientas de desarrollo completa de GCC para desarrollo en Fortran.
Para otros lenguajes por favor use ‘guix search gcc toolchain’ (*note
Invoking guix package: guix-search.).


File: guix.es.info,  Node: Invocación de guix git authenticate,  Prev: La cadena de herramientas de GCC,  Up: Desarrollo

8.5 Invocación de ‘guix git authenticate’
=========================================

La orden ‘guix git authenticate’ verifica una revisión de Git siguiendo
las mismas reglas que con los canales (*note verificación de canales:
channel-authentication.).  Es decir, empezando en una revisión dada, se
asegura que todas las revisiones posteriores están firmadas por una
clave OpenPGP cuya huella aparece en el archivo ‘.guix-authorizations’
de su revisión o revisiones antecesoras.

   Encontrará útil esta orden si mantiene un canal.  Pero de hecho, este
sistema de verificación es útil en un contexto más amplio, por lo que
quizá quiera usarlo para repositorios de Git que no estén relacionados
con Guix.

   La sintaxis general es:

     guix git authenticate REVISIÓN FIRMA [OPCIONES...]

   De manera predeterminada esta orden verifica la copia de trabajo de
Git en el directorio actual; no muestra nada y termina con un código de
salida cero en caso satisfactorio y con un valor distinto a cero en caso
de fallo.  REVISIÓN denota la primera revisión a partir de la cual la
verificación tiene lugar, y FIRMA es la huella de OpenPGP de la clave
pública usada para firmar REVISIÓN.  Juntas forman la “presentación del
canal” (*note presentación del canal: channel-authentication.).  Las
siguientes opciones le permiten controlar con más detalle el proceso.

‘--repository=DIRECTORIO’
‘-r DIRECTORIO’
     Usa el repositorio Git en DIRECTORIO en vez del directorio actual.

‘--keyring=REFERENCIA’
‘-k REFERENCIA’
     Carga el anillo de claves desde REFERENCIA, la rama de referencia
     como por ejemplo ‘origin/keyring’ o ‘mi-anillo-de-claves’.  La rama
     debe contener las claves públicas de OpenPGP en archivos ‘.key’,
     binarios o con “armadura ASCII’.  De manera predeterminada el
     anillo de claves se carga de la rama con nombre ‘keyring’.

‘--stats’
     Muestra las estadísticas de firmas de revisiones tras finalizar.

‘--cache-key=CLAVE’
     Las revisiones verificadas previamente se almacenan en un archivo
     bajo ‘~/.cache/guix/authentication’.  Esta opción fuerza el
     almacenamiento en el archivo CLAVE de dicho directorio.

‘--historical-authorizations=ARCHIVO’
     De manera predeterminada, cualquier revisión cuyo antecesor o
     antecesores carezcan del archivo ‘.guix-authorizations’ no se
     considera auténtica.  En contraste, esta opción considera las
     autorizaciones en ARCHIVO para cualquier revisión que carezca de
     ‘.guix-authorizations’.  El formato de ARCHIVO es el mismo que el
     de ‘.guix-authorizations’ (*note formato de ‘.guix-authorizations’:
     channel-authorizations.).


File: guix.es.info,  Node: Interfaz programática,  Next: Utilidades,  Prev: Desarrollo,  Up: Top

9 Interfaz programática
***********************

GNU Guix proporciona viarias interfaces programáticas Scheme (APIs) para
definir, construir y consultar paquetes.  La primera interfaz permite a
las usuarias escribir definiciones de paquetes a alto nivel.  Estas
definiciones referencian conceptos familiares de empaquetamiento, como
el nombre y la versión de un paquete, su sistema de construcción y sus
dependencias.  Estas definiciones se pueden convertir en acciones
concretas de construcción.

   Las acciones de construcción son realizadas por el daemon Guix, en
delegación de las usuarias.  En una configuración estándar, el daemon
tiene acceso de escritura al almacén—el directorio ‘/gnu/store’—mientras
que las usuarias no.  En la configuración recomendada el daemon también
realiza las construcciones en chroots, bajo usuarias específicas de
construcción, para minimizar la interferencia con el resto del sistema.

   Las APIs de nivel más bajo están disponibles para interactuar con el
daemon y el almacén.  Para instruir al daemon para realizar una acción
de construcción, las usuarias realmente proporcionan una “derivación”.
Una derivación es una representación de bajo nivel de las acciones de
construcción a tomar, y el entorno en el que deberían suceder—las
derivaciones son a las definiciones de paquetes lo que es el ensamblador
a los programas en C. El término “derivación” viene del hecho de que los
resultados de la construcción _derivan_ de ellas.

   Este capítulo describe todas estas APIs en orden, empezando por las
definiciones de alto nivel de paquetes.

* Menu:

* Módulos de paquetes::     Paquetes bajo el punto de vista del
                               programador.
* Definición de paquetes::  Definir nuevos paquetes.
* Definición de variantes de paquetes::  Personalización de paquetes.
* Writing Manifests::        The bill of materials of your environment.
* Sistemas de construcción::  Especificar como se construyen los paquetes.
* Fases de construcción::   Fases del proceso de construcción de un
                               paquete.
* Utilidades de construcción::  Herramientas para sus definiciones de
                                   paquete y más.
* Search Paths::             Declaring search path environment variables.
* El almacén::              Manipular el almacén de paquetes.
* Derivaciones::             Interfaz de bajo nivel de las derivaciones de
                               los paquetes.
* La mónada del almacén::  Interfaz puramente funcional del almacén.
* Expresiones-G::            Manipular expresiones de construcción.
* Invocación de guix repl::  Programación de Guix en Guile
* Using Guix Interactively::  Fine-grain interaction at the REPL.


File: guix.es.info,  Node: Módulos de paquetes,  Next: Definición de paquetes,  Up: Interfaz programática

9.1 Módulos de paquetes
=======================

Desde un punto de vista programático, las definiciones de paquetes de la
distribución GNU se proporcionan por módulos Guile en el espacio de
nombres ‘(gnu packages ...)’(1) (*note Guile modules: (guile)Módulos.).
Por ejemplo, el módulo ‘(gnu packages emacs)’ exporta una variable con
nombre ‘emacs’, que está asociada a un objeto ‘<package>’ (*note
Definición de paquetes::).

   El espacio de nombres de módulos ‘(gnu packages ...)’ se recorre
automáticamente en busca de paquetes en las herramientas de línea de
ordenes.  Por ejemplo, cuando se ejecuta ‘guix install emacs’, todos los
módulos ‘(gnu packages ...)’ son procesados hasta encontrar uno que
exporte un objeto de paquete cuyo nombre sea ‘emacs’.  Esta búsqueda de
paquetes se implementa en el módulo ‘(gnu packages)’.

   Las usuarias pueden almacenar definiciones de paquetes en módulos con
nombres diferentes—por ejemplo, ‘(mis-paquetes emacs)’(2).  Existen dos
maneras de hacer visibles estas definiciones de paquetes a las
interfaces de usuaria:

  1. Mediante la adición del directorio que contiene sus módulos de
     paquetes a la ruta de búsqueda con la opción ‘-L’ de ‘guix package’
     y otras órdenes (*note Opciones comunes de construcción::), o
     usando la variable de entorno ‘GUIX_PACKAGE_PATH’ descrita a
     continuación.

  2. Mediante la definición de un “canal” y la configuración de ‘guix
     pull’ de manera que se actualice desde él.  Un canal es
     esencialmente un repositorio Git que contiene módulos de paquetes.
     *Note Canales::, para más información sobre cómo definir y usar
     canales.

   ‘GUIX_PACKAGE_PATH’ funciona de forma similar a otras variables de
rutas de búsqueda:

 -- Variable de entorno: GUIX_PACKAGE_PATH
     Es una lista separada por dos puntos de directorios en los que se
     buscarán módulos de paquetes adicionales.  Los directorios
     enumerados en esta variable tienen preferencia sobre los propios
     módulos de la distribución.

   La distribución es “auto-contenida” y completamente “basada en el
lanzamiento inicial”: cada paquete se construye basado únicamente en
otros paquetes de la distribución.  La raíz de este grafo de
dependencias es un pequeño conjunto de “binarios del lanzamiento
inicial”, proporcionados por el módulo ‘(gnu packages bootstrap)’.  Para
más información sobre el lanzamiento inicial, *note Lanzamiento
inicial::.

   ---------- Footnotes ----------

   (1) Fíjese que los paquetes bajo el espacio de nombres de módulo
‘(gnu packages ...)’ no son necesariamente “paquetes GNU”.  Este esquema
de nombrado de módulos sigue la convención habitual de Guile para el
nombrado de módulos: ‘gnu’ significa que estos módulos se distribuyen
como parte del sistema GNU, y ‘packages’ identifica módulos que definen
paquetes.

   (2) Fíjese que el nombre de archivo y el nombre de módulo deben
coincidir.  Por ejemplo, el módulo ‘(mis-paquetes emacs)’ debe
almacenarse en el archivo ‘mis-paquetes/emacs.scm’ en relación con la
ruta de carga especificada con ‘--load-path’ o ‘GUIX_PACKAGE_PATH’.
*Note (guile)Modules and the File System::, para obtener detalles.


File: guix.es.info,  Node: Definición de paquetes,  Next: Definición de variantes de paquetes,  Prev: Módulos de paquetes,  Up: Interfaz programática

9.2 Definición de paquetes
==========================

La interfaz de alto nivel de las definiciones de paquetes está
implementada en los módulos ‘(guix packages)’ y ‘(guix build-system)’.
Como un ejemplo, la definición de paquete, o “receta”, para el paquete
GNU Hello es como sigue:

     (define-module (gnu packages hello)
       #:use-module (guix packages)
       #:use-module (guix download)
       #:use-module (guix build-system gnu)
       #:use-module (guix licenses)
       #:use-module (gnu packages gawk))

     (define-public hello
       (package
         (name "hello")
         (version "2.10")
         (source (origin
                   (method url-fetch)
                   (uri (string-append "mirror://gnu/hello/hello-" version
                                       ".tar.gz"))
                   (sha256
                    (base32
                     "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i"))))
         (build-system gnu-build-system)
         (arguments '(#:configure-flags '("--enable-silent-rules")))
         (inputs (list gawk))
         (synopsis "Hello, GNU world: An example GNU package")
         (description "Guess what GNU Hello prints!")
         (home-page "https://www.gnu.org/software/hello/")
         (license gpl3+)))

Sin ser una experta en Scheme—pero conociendo un poco de inglés—, la
lectora puede haber supuesto el significado de varios campos aquí.  Esta
expresión asocia la variable ‘hello’ al objeto ‘<package>’, que
esencialmente es un registro (*note Scheme records: (guile)SRFI-9.).
Este objeto de paquete puede ser inspeccionado usando los procedimientos
encontrados en el módulo ‘(guix packages)’; por ejemplo, ‘(package-name
hello)’ devuelve—¡sorpresa!—‘"hello"’.

   Con suerte, puede que sea capaz de importar parte o toda la
definición del paquete de su interés de otro repositorio, usando la
orden ‘guix import’ (*note Invocación de guix import::).

   En el ejemplo previo, ‘hello’ se define en un módulo para ella, ‘(gnu
packages hello)’.  Técnicamente, esto no es estrictamente necesario,
pero es conveniente hacerlo: todos los paquetes definidos en módulos
bajo ‘(gnu packages ...)’ se reconocen automáticamente en las
herramientas de línea de órdenes (*note Módulos de paquetes::).

   Hay unos pocos puntos que merece la pena destacar de la definición de
paquete previa:

   • El campo ‘source’ del paquete es un objeto ‘<origin>’ (*note
     Referencia de origin::, para la referencia completa).  Aquí se usa
     el método ‘url-fetch’ de ‘(guix download)’, lo que significa que la
     fuente es un archivo a descargar por FTP o HTTP.

     El prefijo ‘mirror://gnu’ instruye a ‘url-fetch’ para usar uno de
     los espejos GNU definidos en ‘(guix download)’.

     El campo ‘sha256’ especifica el hash SHA256 esperado del archivo
     descargado.  Es obligatorio, y permite a Guix comprobar la
     integridad del archivo.  La forma ‘(base32 ...)’ introduce la
     representación base32 del hash.  Puede obtener esta información con
     ‘guix download’ (*note Invocación de guix download::) y ‘guix hash’
     (*note Invocación de guix hash::).

     Cuando sea necesario, la forma ‘origin’ también puede tener un
     campo ‘patches’ con la lista de parches a ser aplicados, y un campo
     ‘snippet’ con una expresión Scheme para modificar el código fuente.

   • El campo ‘build-system’ especifica el procedimiento de construcción
     del paquete (*note Sistemas de construcción::).  Aquí,
     ‘gnu-build-system’ representa el familiar sistema de construcción
     GNU, donde los paquetes pueden configurarse, construirse e
     instalarse con la secuencia de ordenes habitual ‘./configure &&
     make && make check && make install’.

     Cuando comience a empaquetar software no trivial puede que necesite
     herramientas para manipular estas fases de construcción, manipular
     archivos, etcétera.  *Note Utilidades de construcción:: para
     obtener más información sobre este tema.

   • El campo ‘arguments’ especifica las opciones para el sistema de
     construcción (*note Sistemas de construcción::).  Aquí son
     interpretadas por ‘gnu-build-system’ como una petición de ejecutar
     ‘configure’ con la opción ‘--enable-silent-rules’.

     What about these quote (‘'’) characters?  They are Scheme syntax to
     introduce a literal list; ‘'’ is synonymous with ‘quote’.
     Sometimes you’ll also see ‘`’ (a backquote, synonymous with
     ‘quasiquote’) and ‘,’ (a comma, synonymous with ‘unquote’).  *Note
     quoting: (guile)Expression Syntax, for details.  Here the value of
     the ‘arguments’ field is a list of arguments passed to the build
     system down the road, as with ‘apply’ (*note ‘apply’: (guile)Fly
     Evaluation.).

     La secuencia almohadilla-dos puntos (‘#:’) define una “palabra
     clave” Scheme (*note (guile)Keywords::), y ‘#:configure-flags’ es
     una palabra clave usada para pasar un parámetro nominal al sistema
     de construcción (*note (guile)Coding With Keywords::).

   • The ‘inputs’ field specifies inputs to the build process—i.e.,
     build-time or run-time dependencies of the package.  Here, we add
     an input, a reference to the ‘gawk’ variable; ‘gawk’ is itself
     bound to a ‘<package>’ object.

     Fíjese que no hace falta que GCC, Coreutils, Bash y otras
     herramientas esenciales se especifiquen como entradas aquí.  En vez
     de eso, ‘gnu-build-system’ se hace cargo de asegurar que están
     presentes (*note Sistemas de construcción::).

     No obstante, cualquier otra dependencia debe ser especificada en el
     campo ‘inputs’.  Las dependencias no especificadas aquí simplemente
     no estarán disponibles para el proceso de construcción, provocando
     posiblemente un fallo de construcción.

   *Note Referencia de package::, para una descripción completa de los
campos posibles.

     Más allá: Intimidated by the Scheme language or curious about it?
     The Cookbook has a short section to get started that recaps some of
     the things shown above and explains the fundamentals.  *Note
     (guix-cookbook)A Scheme Crash Course::, for more information.

   Una vez la definición de paquete esté en su lugar, el paquete puede
ser construido realmente usando la herramienta de línea de órdenes ‘guix
build’ (*note Invocación de guix build::), pudiendo resolver cualquier
fallo de construcción que encuentre (*note Depuración de fallos de
construcción::).  Puede volver a la definición del paquete fácilmente
usando la orden ‘guix edit’ (*note Invocación de guix edit::).  *Note
Pautas de empaquetamiento::, para más información sobre cómo probar
definiciones de paquetes, y *note Invocación de guix lint::, para
información sobre cómo comprobar la consistencia del estilo de una
definición.  Por último, *note Canales::, para información sobre cómo
extender la distribución añadiendo sus propias definiciones de paquetes
en un “canal”.

   Finalmente, la actualización de la definición con una nueva versión
oficial puede ser automatizada parcialmente por la orden ‘guix refresh’
(*note Invocación de guix refresh::).

   Tras el telón, una derivación correspondiente al objeto ‘<package>’
se calcula primero mediante el procedimiento ‘package-derivation’.  Esta
derivación se almacena en un archivo ‘.drv’ bajo ‘/gnu/store’.  Las
acciones de construcción que prescribe pueden entonces llevarse a cabo
usando el procedimiento ‘build-derivations’ (*note El almacén::).

 -- Procedimiento Scheme: package-derivation ALMACÉN PAQUETE [SISTEMA]
     Devuelve el objeto ‘<derivation>’ del PAQUETE pra el SISTEMA (*note
     Derivaciones::).

     PAQUETE debe ser un objeto ‘<package>’ válido, y SISTEMA debe ser
     una cadena que denote el tipo de sistema objetivo—por ejemplo,
     ‘"x86_64-linux"’ para un sistema GNU x86_64 basado en Linux.
     ALMACÉN debe ser una conexión al daemon, que opera en el almacén
     (*note El almacén::).

De manera similar, es posible calcular una derivación que construye de
forma cruzada un paquete para otro sistema:

 -- Procedimiento Scheme: package-cross-derivation ALMACÉN PAQUETE
          PLATAFORMA [SISTEMA]
     Devuelve el objeto ‘<derivation>’ de PAQUETE compilado de forma
     cruzada desde SISTEMA a PLATAFORMA.

     PLATAFORMA debe ser una tripleta GNU válida que identifique al
     hardware y el sistema operativo deseado, como por ejemplo
     ‘"aarch64-linux-gnu"’ (*note (autoconf)Specifying Target
     Triplets::).

   Una vez tenga sus definiciones de paquetes puede definir facilmente
_variantes_ de dichos paquetes.  *Note Definición de variantes de
paquetes:: para obtener más información sobre ello.

* Menu:

* Referencia de package::    El tipo de datos de los paquetes.
* Referencia de origin::     El tipo de datos de orígenes.


File: guix.es.info,  Node: Referencia de package,  Next: Referencia de origin,  Up: Definición de paquetes

9.2.1 Referencia de ‘package’
-----------------------------

Esta sección resume todas las opciones disponibles en declaraciones
‘package’ (*note Definición de paquetes::).

 -- Tipo de datos: package
     Este es el tipo de datos que representa la receta de un paquete.

     ‘name’
          El nombre del paquete, como una cadena.

     ‘version’
          The version of the package, as a string.  *Note Versiones
          numéricas::, for guidelines.

     ‘source’
          Un objeto que determina cómo se debería obtener el código
          fuente del paquete.  La mayor parte del tiempo, es un objeto
          ‘origin’, que denota un archivo obtenido de Internet (*note
          Referencia de origin::).  También puede ser cualquier otro
          objeto “tipo-archivo” como ‘local-file’, que denota un archivo
          del sistema local de archivos (*note ‘local-file’:
          Expresiones-G.).

     ‘build-system’
          El sistema de construcción que debe ser usado para construir
          el paquete (*note Sistemas de construcción::).

     ‘arguments’ (predeterminados: ‘'()’)
          The arguments that should be passed to the build system (*note
          Sistemas de construcción::).  This is a list, typically
          containing sequential keyword-value pairs, as in this example:

               (package
                 (name "example")
                 ;; several fields omitted
                 (arguments
                   (list #:tests? #f                     ;skip tests
                         #:make-flags #~'("VERBOSE=1")   ;pass flags to 'make'
                         #:configure-flags #~'("--enable-frobbing"))))

          The exact set of supported keywords depends on the build
          system (*note Sistemas de construcción::), but you will find
          that almost all of them honor ‘#:configure-flags’,
          ‘#:make-flags’, ‘#:tests?’, and ‘#:phases’.  The ‘#:phases’
          keyword in particular lets you modify the set of build phases
          for your package (*note Fases de construcción::).

     ‘inputs’ (predeterminadas: ‘'()’)
     ‘native-inputs’ (predeterminadas: ‘'()’)
     ‘propagated-inputs’ (predeterminadas: ‘'()’)
          These fields list dependencies of the package.  Each element
          of these lists is either a package, origin, or other
          “file-like object” (*note Expresiones-G::); to specify the
          output of that file-like object that should be used, pass a
          two-element list where the second element is the output (*note
          Paquetes con múltiples salidas::, for more on package
          outputs).  For example, the list below specifies three inputs:

               (list libffi libunistring
                     `(,glib "bin"))      ;the "bin" output of GLib

          In the example above, the ‘"out"’ output of ‘libffi’ and
          ‘libunistring’ is used.

               Compatibility Note: Until version 1.3.0, input lists were
               a list of tuples, where each tuple has a label for the
               input (a string) as its first element, a package, origin,
               or derivation as its second element, and optionally the
               name of the output thereof that should be used, which
               defaults to ‘"out"’.  For example, the list below is
               equivalent to the one above, but using the “old input
               style”:

                    ;; Old input style (deprecated).
                    `(("libffi" ,libffi)
                      ("libunistring" ,libunistring)
                      ("glib:bin" ,glib "bin"))  ;the "bin" output of GLib

               This style is now deprecated; it is still supported but
               support will be removed in a future version.  It should
               not be used for new package definitions.  *Note Invoking
               guix style::, on how to migrate to the new style.

          La distinción entre ‘native-inputs’ y ‘inputs’ es necesaria
          cuando se considera la compilación cruzada.  Cuando se compila
          desde una arquitectura distinta, las dependencias enumeradas
          en ‘inputs’ son construidas para la arquitectura _objetivo_;
          de modo contrario, las dependencias enumeradas en
          ‘native-inputs’ se construyen para la arquitectura de la
          máquina de _construcción_.

          ‘native-inputs’ se usa típicamente para enumerar herramientas
          necesarias en tiempo de construcción, pero no en tiempo de
          ejecución, como Autoconf, Automake, pkg-config, Gettext o
          Bison.  ‘guix lint’ puede informar de probables errores en
          este área (*note Invocación de guix lint::).

          Por último, ‘propagated-inputs’ es similar a ‘inputs’, pero
          los paquetes especificados se instalarán automáticamente a los
          perfiles (*note el rol de los perfiles en Guix:
          Características.) junto al paquete al que pertenecen (*note
          ‘guix package’: package-cmd-propagated-inputs, para
          información sobre cómo ‘guix package’ gestiona las entradas
          propagadas).

          Por ejemplo esto es necesario cuando se empaqueta una
          biblioteca C/C++ que necesita cabeceras de otra biblioteca
          para compilar, o cuando un archivo pkg-config se refiere a
          otro a través de su campo ‘Requires’.

          Otro ejemplo donde ‘propagated-inputs’ es útil es en lenguajes
          que carecen de la facilidad de almacenar la ruta de búsqueda
          de tiempo de ejecución de la misma manera que el campo
          ‘RUNPATH’ de los archivos ELF; esto incluye Guile, Python,
          Perl y más.  Cuando se empaquetan bibliotecas escritas en
          estos lenguajes, enumerar en ‘propagated-inputs’ en vez de en
          ‘inputs’ las dependencias de tiempo de ejecución permite
          asegurarse de encontrar el código de las bibliotecas de las
          que dependan en tiempo de ejecución.

     ‘outputs’ (predeterminada: ‘'("out")’)
          La lista de nombres de salidas del paquete.  *Note Paquetes
          con múltiples salidas::, para usos típicos de salidas
          adicionales.

     ‘native-search-paths’ (predeterminadas: ‘'()’)
     ‘search-paths’ (predeterminadas: ‘'()’)
          A list of ‘search-path-specification’ objects describing
          search-path environment variables honored by the package.
          *Note Search Paths::, for more on search path specifications.

          As for inputs, the distinction between ‘native-search-paths’
          and ‘search-paths’ only matters when cross-compiling.  In a
          cross-compilation context, ‘native-search-paths’ applies
          exclusively to native inputs whereas ‘search-paths’ applies
          only to host inputs.

          Packages such as cross-compilers care about target inputs—for
          instance, our (modified) GCC cross-compiler has
          ‘CROSS_C_INCLUDE_PATH’ in ‘search-paths’, which allows it to
          pick ‘.h’ files for the target system and _not_ those of
          native inputs.  For the majority of packages though, only
          ‘native-search-paths’ makes sense.

     ‘replacement’ (predeterminado: ‘1.0’)
          Esto debe ser o bien ‘#f’ o bien un objeto package que será
          usado como “reemplazo” para ete paquete.  *Note injertos:
          Actualizaciones de seguridad, para más detalles.

     ‘synopsis’
          Una descripción en una línea del paquete.

     ‘description’
          A more elaborate description of the package, as a string in
          Texinfo syntax.

     ‘license’
          La licencia del paquete; un valor de ‘(guix licenses)’, o una
          lista de dichos valores.

     ‘home-page’
          La URL de la página principal del paquete, como una cadena.

     ‘supported-systems’ (predeterminados: ‘%supported-systems’)
          La lista de sistemas en los que se mantiene el paquete, como
          cadenas de la forma ‘arquitectura-núcleo’, por ejemplo
          ‘"x86_64-linux"’.

     ‘location’ (predeterminada: la localización de los fuentes de la forma ‘package’)
          La localización de las fuentes del paquete.  Es útil forzar su
          valor cuando se hereda de otro paquete, en cuyo caso este
          campo no se corrige automáticamente.

 -- Sintaxis Scheme: this-package
     Cuando se usa en el _ámbito léxico_ de la definición de un paquete,
     este identificador resuelve al paquete que se está definiendo.

     El ejemplo previo muestra cómo añadir un paquete como su propia
     entrada nativa cuando se compila de forma cruzada:

          (package
            (name "guile")
            ;; ...

            ;; When cross-compiled, Guile, for example, depends on
            ;; a native version of itself.  Add it here.
            (native-inputs (if (%current-target-system)
                               (list this-package)
                               '())))

     Es un error hacer referencia a ‘this-package’ fuera de la
     definición de un paquete.

   The following helper procedures are provided to help deal with
package inputs.

 -- Scheme Procedure: lookup-package-input PACKAGE NAME
 -- Scheme Procedure: lookup-package-native-input PACKAGE NAME
 -- Scheme Procedure: lookup-package-propagated-input PACKAGE NAME
 -- Scheme Procedure: lookup-package-direct-input PACKAGE NAME
     Look up NAME among PACKAGE’s inputs (or native, propagated, or
     direct inputs).  Return it if found, ‘#f’ otherwise.

     NAME is the name of a package depended on.  Here’s how you might
     use it:

          (use-modules (guix packages) (gnu packages base))

          (lookup-package-direct-input coreutils "gmp")
          ⇒ #<package gmp@6.2.1 ...>

     In this example we obtain the ‘gmp’ package that is among the
     direct inputs of ‘coreutils’.

   Sometimes you will want to obtain the list of inputs needed to
_develop_ a package—all the inputs that are visible when the package is
compiled.  This is what the ‘package-development-inputs’ procedure
returns.

 -- Scheme Procedure: package-development-inputs PACKAGE [SYSTEM]
          [#:target #f] Return the list of inputs required by
     PACKAGE for development purposes on SYSTEM.  When TARGET is true,
     return the inputs needed to cross-compile PACKAGE from SYSTEM to
     TARGET, where TARGET is a triplet such as ‘"aarch64-linux-gnu"’.

     Note that the result includes both explicit inputs and implicit
     inputs—inputs automatically added by the build system (*note
     Sistemas de construcción::).  Let us take the ‘hello’ package to
     illustrate that:

          (use-modules (gnu packages base) (guix packages))

          hello
          ⇒ #<package hello@2.10 gnu/packages/base.scm:79 7f585d4f6790>

          (package-direct-inputs hello)
          ⇒ ()

          (package-development-inputs hello)
          ⇒ (("source" ...) ("tar" #<package tar@1.32 ...>) ...)

     In this example, ‘package-direct-inputs’ returns the empty list,
     because ‘hello’ has zero explicit dependencies.  Conversely,
     ‘package-development-inputs’ includes inputs implicitly added by
     ‘gnu-build-system’ that are required to build ‘hello’: tar, gzip,
     GCC, libc, Bash, and more.  To visualize it, ‘guix graph hello’
     would show you explicit inputs, whereas ‘guix graph -t bag hello’
     would include implicit inputs (*note Invocación de guix graph::).

   Debido a que los paquetes son objetos Scheme normales que capturan un
grafo de dependencias completo y se asocian a procedimientos de
construcción, habitualmente es útil escribir procedimientos que toman un
paquete y devuelven una versión modificada de acuerdo a ciertos
parámetros.  A continuación se muestran algunos ejemplos:

 -- Procedimiento Scheme: package-with-c-toolchain PAQUETE CADENA
     Devuelve una variación de PAQUETE que usa CADENA en vez de la
     cadena de herramientas de construcción de C/C++ de GNU
     predeterminada.  CADENA debe ser una lista de entradas (tuplas
     etiqueta/paquete) que proporcionen una funcionalidad equivalente a
     la del paquete ‘gcc-toolchain’.

     El siguiente ejemplo devuelve una variación del paquete ‘hello’ que
     se ha construido con GCC 10.x y el resto de la cadena de
     herramientas de construcción de GNU (Binutils y la biblioteca de C
     de GNU) en vez de la cadena de construcción predeterminada:

          (let ((cadena (specification->package "gcc-toolchain@10")))
            ;; El nombre de la entrada debe ser "toolchain".
            (package-with-c-toolchain hello `(("toolchain" ,cadena))))

     La cadena de herramientas de construcción es parte de las “entradas
     impícitas” de los paquetes—habitualmente no se enumera como parte
     de los distintos campos de entrada (“inputs”) sino que el sistema
     de construcción es quién la incorpora.  Por lo tanto este
     procedimiento funciona cambiando el sistema de construcción del
     PAQUETE de modo que se incorpora CADENA en vez de los valores
     predeterminados.  *note Sistemas de construcción:: para obtener más
     información sobre sistemas de construcción.


File: guix.es.info,  Node: Referencia de origin,  Prev: Referencia de package,  Up: Definición de paquetes

9.2.2 Referencia de ‘origin’
----------------------------

Esta sección documenta los “orígenes”.  Una declaración de origen
(‘origin’) especifica datos que se deben “producir”—descargandose,
habitualmente—y el hash de su contenido se conoce de antemano.  Los
origenes se usan habitualmente para reprensentar el código fuente de los
paquetes (*note Definición de paquetes::).  Por esta razón la forma
sintáctica ‘origin’ le permite declarar tanto parches para aplicar al
código fuente original como fragmentos de código que para su
modificación.

 -- Tipo de datos: origin
     Este es el tipo de datos que representa un origen de código fuente.

     ‘uri’
          Un objeto que contiene el URI de las fuentes.  El tipo de
          objeto depende del valor de ‘method’ (véase a continuación).
          Por ejemplo, cuando se usa el método URL-FETCH de ‘(guix
          download)’, los valores adecuados para ‘uri’ son: una cadena
          que contiene una URL, o una lista de cadenas.

     ‘method’
          A monadic procedure that handles the given URI.  The procedure
          must accept at least three arguments: the value of the ‘uri’
          field and the hash algorithm and hash value specified by the
          ‘hash’ field.  It must return a store item or a derivation in
          the store monad (*note La mónada del almacén::); most methods
          return a fixed-output derivation (*note Derivaciones::).

          Los métodos habitualmente usados incluyen ‘url-fetch’, que
          obtiene datos a partir de una URL, y ‘git-fetch’, que obtiene
          datos de un repositorio Git (véase a continuación).

     ‘sha256’
          Un vector de bytes que contiene el hash SHA-256 de las
          fuentes.  Es equivalente a proporcionar un objeto SHA256
          ‘content-hash’ en el campo ‘hash’ descrito a continuación.

     ‘hash’
          El objeto ‘content-hash’ de las fuentes—véase a continuación
          cómo usar ‘content-hash’.

          Puede obtener esta información usando ‘guix download’ (*note
          Invocación de guix download::) o ‘guix hash’ (*note Invocación
          de guix hash::).

     ‘file-name’ (predeterminado: ‘#f’)
          El nombre de archivo bajo el que el código fuente se
          almacenará.  Cuando este es ‘#f’, un valor predeterminado
          sensato se usará en la mayor parte de casos.  En caso de que
          las fuentes se obtengan de una URL, el nombre de archivo de la
          URL se usará.  Para copias de trabajo de sistemas de control
          de versiones, se recomienda proporcionar el nombre de archivo
          explícitamente ya que el predeterminado no es muy descriptivo.

     ‘patches’ (predeterminados: ‘'()’)
          Una lista de nombres de archivos, orígenes u objetos
          tipo-archivo (*note objetos “tipo-archivo”: Expresiones-G.)
          apuntando a parches que deben ser aplicados a las fuentes.

          La lista de parches debe ser incondicional.  En particular, no
          puede depender del valor de ‘%current-system’ o
          ‘%current-target-system’.

     ‘snippet’ (predeterminado: ‘#f’)
          Una expresión-G (*note Expresiones-G::) o expresión-S que se
          ejecutará en el directorio de fuentes.  Esta es una forma
          conveniente de modificar el software, a veces más que un
          parche.

     ‘patch-flags’ (predeterminadas: ‘'("-p1")’)
          Una lista de opciones de línea de órdenes que deberían ser
          pasadas a la orden ‘patch’.

     ‘patch-inputs’ (predeterminada: ‘#f’)
          Paquetes o derivaciones de entrada al proceso de aplicación de
          los parches.  Cuando es ‘#f’, se proporciona el conjunto
          habitual de entradas necesarias para la aplicación de parches,
          como GNU Patch.

     ‘modules’ (predeterminados: ‘'()’)
          Una lista de módulos Guile que debe ser cargada durante el
          proceso de aplicación de parches y mientras se ejecuta el
          código del campo ‘snippet’.

     ‘patch-guile’ (predeterminado: ‘#f’)
          El paquete Guile que debe ser usado durante la aplicación de
          parches.  Cuando es ‘#f’ se usa un valor predeterminado.

 -- Tipo de datos: content-hash VALOR [ALGORITMO]
     Construye un objeto del hash del contenido para el ALGORITMO
     proporcionado, y con VALOR como su valor.  Cuando se omite
     ALGORITMO se asume que es ‘sha256’.

     VALOR puede ser una cadena literal, en cuyo caso se decodifica en
     base32, o un vector de bytes.

     Las siguientes opciones equivalentes entre sí:

          (content-hash "05zxkyz9bv3j9h0xyid1rhvh3klhsmrpkf3bcs6frvlgyr2gwilj")
          (content-hash "05zxkyz9bv3j9h0xyid1rhvh3klhsmrpkf3bcs6frvlgyr2gwilj"
                        sha256)
          (content-hash (base32
                         "05zxkyz9bv3j9h0xyid1rhvh3klhsmrpkf3bcs6frvlgyr2gwilj"))
          (content-hash (base64 "kkb+RPaP7uyMZmu4eXPVkM4BN8yhRd8BTHLslb6f/Rc=")
                        sha256)

     Técnicamente, ‘content-hash’ se implementa actualmente con un
     macro.  Realiza comprobaciones de seguridad en tiempo de expansión,
     cuando es posible, como asegurarse de que VALOR tiene el tamaño
     adecuado para ALGORITMO.

   Como se ha visto previamente, la forma exacta en la que un origen
hace referencia a los datos se determina por su campo ‘method’.  El
módulo ‘(guix download)’ proporciona el método más común, ‘url-fetch’,
descrito a continuación.

 -- Procedimiento Scheme: url-fetch URL ALGO-HASH HASH [nombre]
          [#:executable? #f]
     Devuelve una derivación de salida fija que obtiene datos desde URL
     (una cadena o una lista de cadenas indicando URL alternativas), la
     cual se espera que tenga el hash HASH del tipo ALGO-HASH (un
     símbolo).  De manera predeterminada el nombre de archivo es el
     identificador final de la URL; de manera opcional se puede usar
     NOMBRE para especificar un nombre de archivo diferente.  Cuando
     EXECUTABLE? es verdadero se proporciona el permiso de ejecución al
     archivo descargado.

     Cuando una de las URL comienza con ‘mirror://’, la parte de la
     máquina se interpreta como el nombre de un esquema de espejos,
     obtenido de ‘%mirror-file’.

     De manera alternativa, cuando URL comienza con ‘file://’, devuelve
     el nombre de archivo del almacén correspondiente.

   De igual modo el módulo ‘(guix git-download)’ define el método de
origen ‘git-fetch’, que descarga datos de un repositorio de control de
versiones Git, y el tipo de datos ‘git-reference’, que describe el
repositorio y la revisión que se debe obtener.

 -- Procedimiento Scheme: git-fetch URL ALGO-HASH HASH
     Devuelve una derivación de salida fija que obtiene REF, un objeto
     ‘<git-reference>’.  El hash recursivo de la salida se espera que
     tenga el valor HASH del tipo ALGO-HASH (un símbolo).  Se usa NOMBRE
     para el nombre de archivo, o un nombre genérico si su valor es
     ‘#f’.

 -- Tipo de datos: git-reference
     Este es el tipo de datos que representa una referencia de Git que
     debe obtener el módulo ‘git-fetch’.

     ‘url’
          La URL del repositorio Git que debe clonarse.

     ‘commit’
          This string denotes either the commit to fetch (a hexadecimal
          string), or the tag to fetch.  You can also use a “short”
          commit ID or a ‘git describe’ style identifier such as
          ‘v1.0.1-10-g58d7909c97’.

     ‘recursive?’ (predeterminado: ‘#f’)
          Este valor booleano indica si se obtienen los sub-modulos de
          Git de manera recursiva.

     El siguiente ejemplo representa la etiqueta ‘v2.10’ del repositorio
     de GNU Hello:

          (git-reference
            (url "https://git.savannah.gnu.org/git/hello.git")
            (commit "v2.10"))

     Es equivalente a la siguiente referencia, la cual nombra de manera
     explícita la revisión:

          (git-reference
            (url "https://git.savannah.gnu.org/git/hello.git")
            (commit "dc7dc56a00e48fe6f231a58f6537139fe2908fb9"))

   For Mercurial repositories, the module ‘(guix hg-download)’ defines
the ‘hg-fetch’ origin method and ‘hg-reference’ data type for support of
the Mercurial version control system.

 -- Scheme Procedure: hg-fetch REF HASH-ALGO HASH [name] Return a
          fixed-output derivation that fetches REF, a
     ‘<hg-reference>’ object.  The output is expected to have recursive
     hash HASH of type HASH-ALGO (a symbol).  Use NAME as the file name,
     or a generic name if ‘#false’.


File: guix.es.info,  Node: Definición de variantes de paquetes,  Next: Writing Manifests,  Prev: Definición de paquetes,  Up: Interfaz programática

9.3 Definición de variantes de paquetes
=======================================

One of the nice things with Guix is that, given a package definition,
you can easily _derive_ variants of that package—for a different
upstream version, with different dependencies, different compilation
options, and so on.  Some of these custom packages can be defined
straight from the command line (*note Opciones de transformación de
paquetes::).  This section describes how to define package variants in
code.  This can be useful in “manifests” (*note Writing Manifests::) and
in your own package collection (*note Creación de un canal::), among
others!

   Como se ha mostrado previamente, los paquetes son objetos de primera
clase del lenguage Scheme.  El módulo ‘(guix packages)’ proporciona la
forma sintáctica ‘package’ para definir nuevos objetos de paquetes
(*note Referencia de package::).  La forma más fácil de definir una
variante de un paquete es usar la palabra clave ‘inherit’ junto a
‘package’.  Esto le permite heredar de una definición de paquete y
modificar únicamente los campos que desee.

   Por ejemplo, a partir de la variable ‘hello’, que contiene la
definición de la versión actual de GNU Hello, podría definir de esta
forma una variante para la versión 2.2 (publicada 2006, ¡con solera!):

     (use-modules (gnu packages base))    ;para 'hello'

     (define hello-2.2
       (package
         (inherit hello)
         (version "2.2")
         (source (origin
                   (method url-fetch)
                   (uri (string-append "mirror://gnu/hello/hello-" version
                                       ".tar.gz"))
                   (sha256
                    (base32
                     "0lappv4slgb5spyqbh6yl5r013zv72yqg2pcl30mginf3wdqd8k9"))))))

   El ejemplo previo es equivalente a lo que la opción de transformación
de paquetes ‘--with-source’ realiza.  Esencialmente ‘hello-2.2’ preserva
todos los campos de ‘hello’, excepto ‘version’ y ‘source’, los cuales se
modifican.  Tenca en cuenta que la variable original ‘hello’ todavía
está disponible en el módulo ‘(gnu packages base)’ sin sufrir ningún
cambio.  Cuando define un paquete personalizado como este realmente está
_añadiendo_ una nueva definición de paquete; la orignal sigue
disponible.

   De igual manera puede definir variantes con un conjunto de
dependencias distinto al del paquete original.  Por ejemplo, el paquete
‘gdb’ predeterminado depende de ‘guile’ pero, puesto que es una
dependencia opcional, podría definir una variante que elimina dicha
dependencia de este modo:

     (use-modules (gnu packages gdb))   ;for 'gdb'

     (define gdb-sans-guile
       (package
         (inherit gdb)
         (inputs (modify-inputs (package-inputs gdb)
                   (delete "guile")))))

   The ‘modify-inputs’ form above removes the ‘"guile"’ package from the
‘inputs’ field of ‘gdb’.  The ‘modify-inputs’ macro is a helper that can
prove useful anytime you want to remove, add, or replace package inputs.

 -- Scheme Syntax: modify-inputs INPUTS CLAUSES
     Modify the given package inputs, as returned by ‘package-inputs’ &
     co., according to the given clauses.  Each clause must have one of
     the following forms:

     ‘(delete NAME...)’
          Delete from the inputs packages with the given NAMEs
          (strings).

     ‘(prepend PACKAGE...)’
          Add PACKAGEs to the front of the input list.

     ‘(append PACKAGE...)’
          Add PACKAGEs to the end of the input list.

     The example below removes the GMP and ACL inputs of Coreutils and
     adds libcap to the front of the input list:

          (modify-inputs (package-inputs coreutils)
            (delete "gmp" "acl")
            (prepend libcap))

     The example below replaces the ‘guile’ package from the inputs of
     ‘guile-redis’ with ‘guile-2.2’:

          (modify-inputs (package-inputs guile-redis)
            (replace "guile" guile-2.2))

     The last type of clause is ‘append’, to add inputs at the back of
     the list.

   En ciertos casos encontrará útil escribir funciones («procedimientos»
en el vocabulario de Scheme) que devuelven un paquete en base a ciertos
parámetros.  Por ejemplo, considere la biblioteca ‘luasocket’ para el
lenguaje de programación Lua.  Se desea crear paquetes de ‘luasocket’
para las versiones mayores de Lua.  Una forma de hacerlo es definir un
procedimiento que recibe un paquete Lua y devuelve un paquete
‘luasocket’ que depende de él:

     (define (make-lua-socket name lua)
       ;; Return a luasocket package built with LUA.
       (package
         (name name)
         (version "3.0")
         ;; several fields omitted
         (inputs (list lua))
         (synopsis "Socket library for Lua")))

     (define-public lua5.1-socket
       (make-lua-socket "lua5.1-socket" lua-5.1))

     (define-public lua5.2-socket
       (make-lua-socket "lua5.2-socket" lua-5.2))

   En este ejemplo se han definido los paquetes ‘lua5.1-socket’ y
‘lua5.2-socket’ llamando a ‘crea-lua-socket’ con distintos parámetros.
*Note (guile)Procedures:: para más información sobre procedimientos.  El
hecho de disponer de definiciones públicas de nivel superior de estos
dos paquetes permite que se les haga referencia desde la línea de
órdenes (*note Módulos de paquetes::).

   Estas son variantes muy simples.  Para facilitar esta tarea, el
módulo ‘(guix transformations)’ proporciona una interfaz de alto nivel
que se corresponde directamente con las opciones de transformación de
paquetes más sofisticadas (*note Opciones de transformación de
paquetes::):

 -- Procedimiento Scheme: options->transformation OPCIONES
     Devuelve un procedimiento que, cuando se le proporciona un objeto
     que construir (paquete, derivación, etc.), aplica las
     transformaciones especificadas en OPCIONES y devuelve los objetos
     resultantes.  OPCIONES debe ser una lista de pares símbolo/cadena
     como los siguientes:

          ((with-branch . "guile-gcrypt=master")
           (without-tests . "libgcrypt"))

     Cada símbolo nombra una transformación y la cadena correspondiente
     es el parámetro de dicha transformación.

   Por ejemplo, un manifiesto equivalente a esta orden:

     guix build guix \
       --with-branch=guile-gcrypt=master \
       --with-debug-info=zlib

...  sería algo parecido a esto:

     (use-modules (guix transformations))

     (define transforma
       ;; El procedimiento de transformación del paquete.
       (options->transformation
        '((with-branch . "guile-gcrypt=master")
          (with-debug-info . "zlib"))))

     (packages->manifest
      (list (transforma (specification->package "guix"))))

   El procedimiento ‘options->transformation’ es conveniente, pero quizá
no es tan flexible como pudiese desear.  ¿Cómo se ha implementado?  Es
posible que ya se haya percatado de que la mayoría de las opciones de
transformación de paquetes van más allá de los cambios superficiales
mostrados en los primeros ejemplos de esta sección: implican
“reescritura de entradas”, lo que significa que el grafo de dependencias
de un paquete se reescribe sustituyendo entradas específicas por otras.

   La reescritura del grafo de dependencias, con el propósito de
reemplazar paquetes del grafo, es implementada por el procedimiento
‘package-input-rewriting’ en ‘(guix packages)’.

 -- Procedimiento Scheme: package-input-rewriting REEMPLAZOS
          [NOMBRE-REESCRITO] [#:deep? #t]
     Devuelve un procedimiento que, cuando se le pasa un paquete,
     reemplaza sus dependencias directas e indirectas, incluyendo sus
     entradas implícitas cuando DEEP? es verdadero, de acuerdo a
     REEMPLAZOS.  REEMPLAZOS es una lista de pares de paquetes; el
     primer elemento de cada par es el paquete a reemplazar, el segundo
     es el reemplazo.

     Opcionalmente, NOMBRE-REESCRITO es un procedimiento de un parámetro
     que toma el nombre del paquete y devuelve su nuevo nombre tras la
     reescritura.

Considere este ejemplo:

     (define libressl-en-vez-de-openssl
       ;; Esto es un procedimiento para reemplazar OPENSSL
       ;; por LIBRESSL, recursivamente.
       (package-input-rewriting `((,openssl . ,libressl))))

     (define git-con-libressl
       (libressl-en-vez-de-openssl git))

Aquí primero definimos un procedimiento de reescritura que substituye
OPENSSL por LIBRESSL.  Una vez hecho esto, lo usamos para definir una
“variante” del paquete GIT que usa LIBRESSL en vez de OPENSSL.  Esto es
exactamente lo que hace la opción de línea de órdenes ‘--with-input’
(*note ‘--with-input’: Opciones de transformación de paquetes.).

   La siguiente variante de ‘package-input-rewriting’ puede encontrar
paquetes a reemplazar por su nombre en vez de por su identidad.

 -- Procedimiento Scheme: package-input-rewriting/spec REEMPLAZOS
          [#:deep? #t]
     Devuelve un procedimiento que, proporcionado un paquete, realiza
     los REEMPLAZOS proporcionados sobre todo el grafo del paquete,
     incluyendo las entradas implícitas a menos que DEEP? sea falso.
     REEMPLAZOS es una lista de pares de especificación y procedimiento;
     cada especificación es una especificación de paquete como ‘"gcc"’ o
     ‘"guile@2"’, y cada procedimiento toma un paquete que corresponda
     con la especificación y devuelve un reemplazo para dicho paquete.

   El ejemplo previo podría ser reescrito de esta forma:

     (define libressl-en-vez-de-openssl
       ;; Reemplaza todos los paquetes llamados "openssl" con LibreSSL.
       (package-input-rewriting/spec `(("openssl" . ,(const libressl)))))

   La diferencia principal en este caso es que, esta vez, los paquetes
se buscan por su especificación y no por su identidad.  En otras
palabras, cualquier paquete en el grafo que se llame ‘openssl’ será
reemplazado.

   Un procedimiento más genérico para reescribir el grafo de
dependencias de un paquete es ‘package-mapping’: acepta cambios
arbitrarios sobre nodos del grafo.

 -- Scheme Procedure: package-mapping PROC [CORTAR?] [#:deep? #f]
     Devuelve un procedimiento que, dado un paquete, aplica PROC a todos
     los paquetes de los que depende y devuelve el paquete resultante.
     El procedimiento para la recursión cuando CORTAR? devuelve
     verdadero para un paquete dado.  Cuando DEEP? tiene valor
     verdadero, PROC se aplica también a las entradas implícitas.


File: guix.es.info,  Node: Writing Manifests,  Next: Sistemas de construcción,  Prev: Definición de variantes de paquetes,  Up: Interfaz programática

9.4 Writing Manifests
=====================

‘guix’ commands let you specify package lists on the command line.  This
is convenient, but as the command line becomes longer and less trivial,
it quickly becomes more convenient to have that package list in what we
call a “manifest”.  A manifest is some sort of a “bill of materials”
that defines a package set.  You would typically come up with a code
snippet that builds the manifest, store it in a file, say
‘manifest.scm’, and then pass that file to the ‘-m’ (or ‘--manifest’)
option that many ‘guix’ commands support.  For example, here’s what a
manifest for a simple package set might look like:

     ;; Manifest for three packages.
     (specifications->manifest '("gcc-toolchain" "make" "git"))

   Once you have that manifest, you can pass it, for example, to ‘guix
package’ to install just those three packages to your profile (*note
‘-m’ option of ‘guix package’: profile-manifest.):

     guix package -m manifest.scm

...  or you can pass it to ‘guix shell’ (*note ‘-m’ option of ‘guix
shell’: shell-manifest.) to spawn an ephemeral environment:

     guix shell -m manifest.scm

...  or you can pass it to ‘guix pack’ in pretty much the same way
(*note ‘-m’ option of ‘guix pack’: pack-manifest.).  You can store the
manifest under version control, share it with others so they can easily
get set up, etc.

   But how do you write your first manifest?  To get started, maybe
you’ll want to write a manifest that mirrors what you already have in a
profile.  Rather than start from a blank page, ‘guix package’ can
generate a manifest for you (*note ‘guix package --export-manifest’:
export-manifest.):

     # Write to 'manifest.scm' a manifest corresponding to the
     # default profile, ~/.guix-profile.
     guix package --export-manifest > manifest.scm

   Or maybe you’ll want to “translate” command-line arguments into a
manifest.  In that case, ‘guix shell’ can help (*note ‘guix shell
--export-manifest’: shell-export-manifest.):

     # Write a manifest for the packages specified on the command line.
     guix shell --export-manifest gcc-toolchain make git > manifest.scm

   In both cases, the ‘--export-manifest’ option tries hard to generate
a faithful manifest; in particular, it takes package transformation
options into account (*note Opciones de transformación de paquetes::).

     Nota: Manifests are _symbolic_: they refer to packages of the
     channels _currently in use_ (*note Canales::).  In the example
     above, ‘gcc-toolchain’ might refer to version 11 today, but it
     might refer to version 13 two years from now.

     If you want to “pin” your software environment to specific package
     versions and variants, you need an additional piece of information:
     the list of channel revisions in use, as returned by ‘guix
     describe’.  *Note Replicación de Guix::, for more information.

   Once you’ve obtained your first manifest, perhaps you’ll want to
customize it.  Since your manifest is code, you now have access to all
the Guix programming interfaces!

   Let’s assume you want a manifest to deploy a custom variant of GDB,
the GNU Debugger, that does not depend on Guile, together with another
package.  Building on the example seen in the previous section (*note
Definición de variantes de paquetes::), you can write a manifest along
these lines:

     (use-modules (guix packages)
                  (gnu packages gdb)               ;for 'gdb'
                  (gnu packages version-control))  ;for 'git'

     ;; Define a variant of GDB without a dependency on Guile.
     (define gdb-sans-guile
       (package
         (inherit gdb)
         (inputs (modify-inputs (package-inputs gdb)
                   (delete "guile")))))

     ;; Return a manifest containing that one package plus Git.
     (packages->manifest (list gdb-sans-guile git))

   Note that in this example, the manifest directly refers to the ‘gdb’
and ‘git’ variables, which are bound to a ‘package’ object (*note
Referencia de package::), instead of calling ‘specifications->manifest’
to look up packages by name as we did before.  The ‘use-modules’ form at
the top lets us access the core package interface (*note Definición de
paquetes::) and the modules that define ‘gdb’ and ‘git’ (*note Módulos
de paquetes::).  Seamlessly, we’re weaving all this together—the
possibilities are endless, unleash your creativity!

   The data type for manifests as well as supporting procedures are
defined in the ‘(guix profiles)’ module, which is automatically
available to code passed to ‘-m’.  The reference follows.

 -- Data Type: manifest
     Data type representing a manifest.

     It currently has one field:

     ‘entries’
          This must be a list of ‘manifest-entry’ records—see below.

 -- Data Type: manifest-entry
     Data type representing a manifest entry.  A manifest entry contains
     essential metadata: a name and version string, the object (usually
     a package) for that entry, the desired output (*note Paquetes con
     múltiples salidas::), and a number of optional pieces of
     information detailed below.

     Most of the time, you won’t build a manifest entry directly;
     instead, you will pass a package to ‘package->manifest-entry’,
     described below.  In some unusual cases though, you might want to
     create manifest entries for things that are _not_ packages, as in
     this example:

          ;; Manually build a single manifest entry for a non-package object.
          (let ((hello (program-file "hello" #~(display "Hi!"))))
            (manifest-entry
              (name "foo")
              (version "42")
              (item
               (computed-file "hello-directory"
                               #~(let ((bin (string-append #$output "/bin")))
                                   (mkdir #$output) (mkdir bin)
                                    (symlink #$hello
                                             (string-append bin "/hello")))))))

     The available fields are the following:

     ‘name’
     ‘version’
          Name and version string for this entry.

     ‘item’
          A package or other file-like object (*note file-like objects:
          Expresiones-G.).

     ‘output’ (default: ‘"out"’)
          Output of ‘item’ to use, in case ‘item’ has multiple outputs
          (*note Paquetes con múltiples salidas::).

     ‘dependencies’ (predeterminadas: ‘'()’)
          List of manifest entries this entry depends on.  When building
          a profile, dependencies are added to the profile.

          Typically, the propagated inputs of a package (*note
          ‘propagated-inputs’: Referencia de package.) end up having a
          corresponding manifest entry in among the dependencies of the
          package’s own manifest entry.

     ‘search-paths’ (predeterminadas: ‘'()’)
          The list of search path specifications honored by this entry
          (*note Search Paths::).

     ‘properties’ (default: ‘'()’)
          List of symbol/value pairs.  When building a profile, those
          properties get serialized.

          This can be used to piggyback additional metadata—e.g., the
          transformations applied to a package (*note Opciones de
          transformación de paquetes::).

     ‘parent’ (default: ‘(delay #f)’)
          A promise pointing to the “parent” manifest entry.

          This is used as a hint to provide context when reporting an
          error related to a manifest entry coming from a ‘dependencies’
          field.

 -- Scheme Procedure: concatenate-manifests LST
     Concatenate the manifests listed in LST and return the resulting
     manifest.

 -- Scheme Procedure: package->manifest-entry PACKAGE [OUTPUT]
          [#:properties] Return a manifest entry for the OUTPUT
     of package PACKAGE, where OUTPUT defaults to ‘"out"’, and with the
     given PROPERTIES.  By default PROPERTIES is the empty list or, if
     one or more package transformations were applied to PACKAGE, it is
     an association list representing those transformations, suitable as
     an argument to ‘options->transformation’ (*note
     ‘options->transformation’: Definición de variantes de paquetes.).

     The code snippet below builds a manifest with an entry for the
     default output and the ‘send-email’ output of the ‘git’ package:

          (use-modules (gnu packages version-control))

          (manifest (list (package->manifest-entry git)
                          (package->manifest-entry git "send-email")))

 -- Scheme Procedure: packages->manifest PACKAGES
     Return a list of manifest entries, one for each item listed in
     PACKAGES.  Elements of PACKAGES can be either package objects or
     package/string tuples denoting a specific output of a package.

     Using this procedure, the manifest above may be rewritten more
     concisely:

          (use-modules (gnu packages version-control))

          (packages->manifest (list git `(,git "send-email")))

 -- Scheme Procedure: package->development-manifest PACKAGE [SYSTEM]
          [#:target] Return a manifest for the “development inputs”
     of PACKAGE for SYSTEM, optionally when cross-compiling to TARGET.
     Development inputs include both explicit and implicit inputs of
     PACKAGE.

     Like the ‘-D’ option of ‘guix shell’ (*note ‘guix shell -D’:
     shell-development-option.), the resulting manifest describes the
     environment in which one can develop PACKAGE.  For example, suppose
     you’re willing to set up a development environment for Inkscape,
     with the addition of Git for version control; you can describe that
     “bill of materials” with the following manifest:

          (use-modules (gnu packages inkscape)          ;for 'inkscape'
                       (gnu packages version-control))  ;for 'git'

          (concatenate-manifests
           (list (package->development-manifest inkscape)
                 (packages->manifest (list git))))

     In this example, the development manifest that
     ‘package->development-manifest’ returns includes the compiler
     (GCC), the many supporting libraries (Boost, GLib, GTK, etc.), and
     a couple of additional development tools—these are the dependencies
     ‘guix show inkscape’ lists.

   Last, the ‘(gnu packages)’ module provides higher-level facilities to
build manifests.  In particular, it lets you look up packages by
name—see below.

 -- Scheme Procedure: specifications->manifest SPECS
     Given SPECS, a list of specifications such as ‘"emacs@25.2"’ or
     ‘"guile:debug"’, return a manifest.  Specs have the format that
     command-line tools such as ‘guix install’ and ‘guix package’
     understand (*note Invocación de guix package::).

     As an example, it lets you rewrite the Git manifest that we saw
     earlier like this:

          (specifications->manifest '("git" "git:send-email"))

     Notice that we do not need to worry about ‘use-modules’, importing
     the right set of modules, and referring to the right variables.
     Instead, we directly refer to packages in the same way as on the
     command line, which can often be more convenient.


File: guix.es.info,  Node: Sistemas de construcción,  Next: Fases de construcción,  Prev: Writing Manifests,  Up: Interfaz programática

9.5 Sistemas de construcción
============================

Cada definición de paquete especifica un “sistema de construcción” y
parámetros para dicho sistema de construcción (*note Definición de
paquetes::).  Este campo ‘build-system’ representa el procedimiento de
construcción del paquete, así como las dependencias implícitas de dicho
procedimiento de construcción.

   Los sistemas de construcción son objetos ‘<build-system>’.  La
interfaz para crear y manipularlos se proporciona en el módulo ‘(guix
build-system)’, y otros módulos exportan sistemas de construcción
reales.

   En su implementación, los sistemas de construcción primero compilan
los objetos package a objetos “bag”.  Una bolsa (traducción de “bag”) es
como un paquete, pero con menos ornamentos—en otras palabras, una bolsa
es una representación a un nivel más bajo de un paquete, que contiene
todas las entradas de dicho paquete, incluyendo algunas implícitamente
añadidas por el sistema de construcción.  Esta representación intermedia
se compila entonces a una derivación (*note Derivaciones::).  EL
procedimiento ‘package-with-c-toolchain’ es un ejemplo de una forma de
cambiar las entradas implícitas que el sistema de construcción del
paquete incluye (*note ‘package-with-c-toolchain’: Referencia de
package.).

   Los sistemas de construcción aceptan una lista opcional de
“parámetros”.  En las definiciones de paquete, estos son pasados vía el
campo ‘arguments’ (*note Definición de paquetes::).  Normalmente son
parámetros con palabras clave (*note keyword arguments in Guile:
(guile)Optional Arguments.).  El valor de estos parámetros normalmente
se evalúa en la “capa de construcción”—es decir, por un proceso Guile
lanzado por el daemon (*note Derivaciones::).

   El sistema de construcción principal es GNU-BUILD-SYSTEM, el cual
implementa el procedimiento estándar de construcción para GNU y muchos
otros paquetes.  Se proporciona por el módulo ‘(guix build-system gnu)’.

 -- Variable Scheme: gnu-build-system
     GNU-BUILD-SYSTEM representa el sistema de construcción GNU y sus
     variantes (*note configuration and makefile conventions:
     (standards)Configuration.).

     In a nutshell, packages using it are configured, built, and
     installed with the usual ‘./configure && make && make check && make
     install’ command sequence.  In practice, a few additional steps are
     often needed.  All these steps are split up in separate “phases”.
     *Note Fases de construcción::, for more info on build phases and
     ways to customize them.

     Además, este sistema de construcción asegura que el entorno
     “estándar” para paquetes GNU está disponible.  Esto incluye
     herramientas como GCC, libc, Coreutils, Bash, Make, Diffutils, grep
     y sed (vea el módulo ‘(guix build system gnu)’ para una lista
     completa).  A estas las llamamos las “entradas implícitas” de un
     paquete, porque las definiciones de paquete no las mencionan.

     This build system supports a number of keyword arguments, which can
     be passed via the ‘arguments’ field of a package.  Here are some of
     the main parameters:

     ‘#:phases’
          This argument specifies build-side code that evaluates to an
          alist of build phases.  *Note Fases de construcción::, for
          more information.

     ‘#:configure-flags’
          This is a list of flags (strings) passed to the ‘configure’
          script.  *Note Definición de paquetes::, for an example.

     ‘#:make-flags’
          This list of strings contains flags passed as arguments to
          ‘make’ invocations in the ‘build’, ‘check’, and ‘install’
          phases.

     ‘#:out-of-source?’
          This Boolean, ‘#f’ by default, indicates whether to run builds
          in a build directory separate from the source tree.

          When it is true, the ‘configure’ phase creates a separate
          build directory, changes to that directory, and runs the
          ‘configure’ script from there.  This is useful for packages
          that require it, such as ‘glibc’.

     ‘#:tests?’
          This Boolean, ‘#t’ by default, indicates whether the ‘check’
          phase should run the package’s test suite.

     ‘#:test-target’
          This string, ‘"check"’ by default, gives the name of the
          makefile target used by the ‘check’ phase.

     ‘#:parallel-build?’
     ‘#:parallel-tests?’
          These Boolean values specify whether to build, respectively
          run the test suite, in parallel, with the ‘-j’ flag of ‘make’.
          When they are true, ‘make’ is passed ‘-jN’, where N is the
          number specified as the ‘--cores’ option of ‘guix-daemon’ or
          that of the ‘guix’ client command (*note ‘--cores’: Opciones
          comunes de construcción.).

     ‘#:validate-runpath?’
          This Boolean, ‘#t’ by default, determines whether to
          “validate” the ‘RUNPATH’ of ELF binaries (‘.so’ shared
          libraries as well as executables) previously installed by the
          ‘install’ phase.  *Note the ‘validate-runpath’ phase:
          phase-validate-runpath, for details.

     ‘#:substitutable?’
          This Boolean, ‘#t’ by default, tells whether the package
          outputs should be substitutable—i.e., whether users should be
          able to obtain substitutes for them instead of building
          locally (*note Sustituciones::).

     ‘#:allowed-references’
     ‘#:disallowed-references’
          When true, these arguments must be a list of dependencies that
          must not appear among the references of the build results.
          If, upon build completion, some of these references are
          retained, the build process fails.

          This is useful to ensure that a package does not erroneously
          keep a reference to some of it build-time inputs, in cases
          where doing so would, for example, unnecessarily increase its
          size (*note Invocación de guix size::).

     Most other build systems support these keyword arguments.

   Hay definidos otros objetos ‘<build-system>’ para implementar otras
convenciones y herramientas usadas por paquetes de software libre.
Heredan la mayor parte de GNU-BUILD-SYSTEM, y se diferencian
principalmente en el conjunto de entradas implícitamente añadidas al
proceso de construcción, y en la lista de fases ejecutadas.  Algunos de
estos sistemas de construcción se enumeran a continuación.

 -- Variable Scheme: ant-build-system
     ‘(guix build-system ant)’ exporta esta variable.  Implementa el
     procedimiento de construcción de paquetes Java que pueden
     construirse con la herramienta de construcción Ant
     (https://ant.apache.org/).

     Añade tanto ‘ant’ como el “kit de desarrollo Java” (JDK), que
     proporciona el paquete ‘icedtea’, al conjunto de entradas.  Se
     pueden especificar paquetes diferentes con los parámetros ‘#:ant’ y
     ‘#:jdk’, respectivamente.

     Cuando el paquete original no proporciona un archivo Ant apropiado,
     el parámetro ‘#:jar-name’ puede usarse para generar un archivo de
     construcción Ant ‘build.xml’ mínimo con tareas para construir el
     archivo jar especificado.  En este caso, el parámetro
     ‘#:source-dir’ se puede usar para especificar el subdirectorio de
     fuentes, con “src” como valor predeterminado.

     The ‘#:main-class’ parameter can be used with the minimal ant
     buildfile to specify the main class of the resulting jar.  This
     makes the jar file executable.  The ‘#:test-include’ parameter can
     be used to specify the list of junit tests to run.  It defaults to
     ‘(list "**/*Test.java")’.  The ‘#:test-exclude’ can be used to
     disable some tests.  It defaults to ‘(list "**/Abstract*.java")’,
     because abstract classes cannot be run as tests.

     El parámetro ‘#:build-target’ se puede usar para especificar la
     tarea Ant que debe ser ejecutada durante la fase ‘build’.  Por
     defecto se ejecuta la tarea “jar”.

 -- Variable Scheme: android-ndk-build-system
     Esta variable es exportada por ‘(guix build-system android-ndk)’.
     Implementa un procedimiento de construcción para paquetes Android
     NDK (kit de desarrollo nativo) usando un proceso de construcción
     específico de Guix.

     El sistema de construcción asume que los paquetes instalan sus
     archivos de interfaz pública (cabeceras) en el subdirectorio
     ‘include’ de la salida ‘out’ y sus bibliotecas en el subdirectorio
     ‘lib’ de la salida ‘out’".

     También se asume que la unión de todas las dependencias de un
     paquete no tiene archivos en conflicto.

     En este momento no funciona la compilación cruzada - por lo que las
     bibliotecas y los archivos de cabecera se asumen que son locales.

 -- Variable Scheme: asdf-build-system/source
 -- Variable Scheme: asdf-build-system/sbcl
 -- Variable Scheme: asdf-build-system/ecl

     These variables, exported by ‘(guix build-system asdf)’, implement
     build procedures for Common Lisp packages using “ASDF”
     (https://common-lisp.net/project/asdf/).  ASDF is a system
     definition facility for Common Lisp programs and libraries.

     The ‘asdf-build-system/source’ system installs the packages in
     source form, and can be loaded using any common lisp
     implementation, via ASDF.  The others, such as
     ‘asdf-build-system/sbcl’, install binary systems in the format
     which a particular implementation understands.  These build systems
     can also be used to produce executable programs, or lisp images
     which contain a set of packages pre-loaded.

     El sistema de construcción usa convenciones de nombres.  Para
     paquetes binarios, el paquete debería estar prefijado con la
     implementación lisp, como ‘sbcl-’ para ‘asdf-build-system/sbcl’.

     Adicionalmente, el paquete de fuentes correspondiente debe
     etiquetarse usando la misma convención que los paquetes python (vea
     *note Módulos Python::), usando el prefijo ‘cl-’.

     In order to create executable programs and images, the build-side
     procedures ‘build-program’ and ‘build-image’ can be used.  They
     should be called in a build phase after the
     ‘create-asdf-configuration’ phase, so that the system which was
     just built can be used within the resulting image.  ‘build-program’
     requires a list of Common Lisp expressions to be passed as the
     ‘#:entry-program’ argument.

     By default, all the ‘.asd’ files present in the sources are read to
     find system definitions.  The ‘#:asd-files’ parameter can be used
     to specify the list of ‘.asd’ files to read.  Furthermore, if the
     package defines a system for its tests in a separate file, it will
     be loaded before the tests are run if it is specified by the
     ‘#:test-asd-file’ parameter.  If it is not set, the files
     ‘<system>-tests.asd’, ‘<system>-test.asd’, ‘tests.asd’, and
     ‘test.asd’ will be tried if they exist.

     If for some reason the package must be named in a different way
     than the naming conventions suggest, or if several systems must be
     compiled, the ‘#:asd-systems’ parameter can be used to specify the
     list of system names.

 -- Variable Scheme: cargo-build-system
     Esta variable se exporta en ‘(guix build-system cargo)’.  Permite
     la construcción de paquetes usando Cargo, la herramienta de
     construcción del lenguaje de programación Rust
     (https://www.rust-lang.org).

     Automáticamente añade ‘rustc’ y ‘cargo’ al conjunto de entradas.
     Se puede especificar el uso de un paquete Rust distinto con el
     parámetro ‘#:rust’.

     Regular cargo dependencies should be added to the package
     definition similarly to other packages; those needed only at build
     time to native-inputs, others to inputs.  If you need to add
     source-only crates then you should add them to via the
     ‘#:cargo-inputs’ parameter as a list of name and spec pairs, where
     the spec can be a package or a source definition.  Note that the
     spec must evaluate to a path to a gzipped tarball which includes a
     ‘Cargo.toml’ file at its root, or it will be ignored.  Similarly,
     cargo dev-dependencies should be added to the package definition
     via the ‘#:cargo-development-inputs’ parameter.

     In its ‘configure’ phase, this build system will make any source
     inputs specified in the ‘#:cargo-inputs’ and
     ‘#:cargo-development-inputs’ parameters available to cargo.  It
     will also remove an included ‘Cargo.lock’ file to be recreated by
     ‘cargo’ during the ‘build’ phase.  The ‘package’ phase will run
     ‘cargo package’ to create a source crate for future use.  The
     ‘install’ phase installs the binaries defined by the crate.  Unless
     ‘install-source? #f’ is defined it will also install a source crate
     repository of itself and unpacked sources, to ease in future
     hacking on rust packages.

 -- Scheme Variable: chicken-build-system
     This variable is exported by ‘(guix build-system chicken)’.  It
     builds CHICKEN Scheme (https://call-cc.org/) modules, also called
     “eggs” or “extensions”.  CHICKEN generates C source code, which
     then gets compiled by a C compiler, in this case GCC.

     This build system adds ‘chicken’ to the package inputs, as well as
     the packages of ‘gnu-build-system’.

     The build system can’t (yet) deduce the egg’s name automatically,
     so just like with ‘go-build-system’ and its ‘#:import-path’, you
     should define ‘#:egg-name’ in the package’s ‘arguments’ field.

     For example, if you are packaging the ‘srfi-1’ egg:

          (arguments '(#:egg-name "srfi-1"))

     Egg dependencies must be defined in ‘propagated-inputs’, not
     ‘inputs’ because CHICKEN doesn’t embed absolute references in
     compiled eggs.  Test dependencies should go to ‘native-inputs’, as
     usual.

 -- Variable Scheme: copy-build-system
     Esta variable se exporta en ‘(guix build-system copy)’.  Permite la
     construcción de paquetes simples que no necesitan mucha compilación
     y en su mayor parte dependen únicamente de la copia de archivos en
     distintas rutas.

     Añade gran parte de los paquetes de ‘gnu-build-system’ al conjunto
     de entradas.  Por esta razón, ‘copy-build-system’ no necesita toda
     la verborrea que habitualmente requiere ‘trivial-build-system’.

     Para simplificar más aún el proceso de instalación de archivos, se
     expone un parámetro ‘#:install-plan’ para permitir a quien genera
     el paquete especificar dónde van los distintos archivos.  El plan
     de instalación (‘#:install-plan’) es una lista de ‘(FUENTE DESTINO
     [FILTRO])’.  Los FILTROs son opcionales.

        • Cuando FUENTE corresponde con un archivo o un directorio sin
          la barra final, se instala en DESTINO.
             • Si DESTINO contiene una barra al final, FUENTE se instala
               con su nombre de archivo en la ruta DESTINO.
             • En otro caso se instala FUENTE como DESTINO.

        • Cuando FUENTE es un directorio terminado en una barra, o
          cuando se usa algún FILTRO, la barra al final de DESTINO tiene
          el significado que se describió anteriormente.
             • Sin FILTROS, instala todo el _contenido_ de FUENTE en
               DESTINO.
             • Cuando FILTRO contiene ‘#:include’, ‘#:include-regexp’,
               ‘#:exclude’, ‘#:exclude-regexp’, únicamente se
               seleccionan los archivos instalados dependiendo de los
               filtros.  Cada filtro se especifica como una lista de
               cadenas.
                  • Con ‘#:include’, se instalan todos los archivos de
                    la ruta cuyo sufijo corresponda con al menos uno de
                    los elementos de la lista proporcionada.
                  • Con ‘#:include-regexp’ se instalan todos los
                    archivos cuyas rutas relativas correspondan con al
                    menos una de las expresiones regulares en la lista
                    proporcionada.
                  • Los filtros ‘#:exclude’ y ‘#:exclude-regexp’ son
                    complementarios a sus equivalentes inclusivos.  Sin
                    opciones ‘#:include’, se instalan todos los archivos
                    excepto aquellos que correspondan con los filtros de
                    exclusión.  Si se proporcionan tanto inclusiones
                    como exclusiones, las exclusiones tienen efecto
                    sobre los resultados de las inclusiones.
          En todos los casos, las rutas relativas a FUENTE se preservan
          dentro de DESTINO.

     Ejemplos:

        • ‘("foo/bar" "share/my-app/")’: Instala ‘bar’ en
          ‘share/my-app/bar’.
        • ‘("foo/bar" "share/my-app/baz")’: Instala ‘bar’ en
          ‘share/my-app/baz’.
        • ‘("foo/" "share/my-app")’: Instala el contenido de ‘foo’
          dentro de ‘share/my-app’, por ejemplo, instala ‘foo/sub/file’
          en ‘share/my-app/sub/file’.
        • ‘("foo/" "share/my-app" #:include ("sub/file"))’: Instala
          únicamente ‘foo/sub/file’ en ‘share/my-app/sub/file’.
        • ‘("foo/sub" "share/my-app" #:include ("file"))’: Instala
          ‘foo/sub/file’ en ‘share/my-app/file’.

 -- Variable Scheme: clojure-build-system
     Esta variable se exporta en ‘(guix build-system clojure)’.
     Implementa un procedimiento de construcción simple para paquetes
     Clojure (https://clojure.org/) usando directamente ‘compile’ en
     Clojure.  La compilación cruzada no está disponible todavía.

     Añade ‘clojure’, ‘icedtea’ y ‘zip’ al conjunto de entradas.  Se
     pueden especificar paquetes diferentes con los parámetros
     ‘#:clojure’, ‘#:jdk’ y ‘#:zip’, respectivamente.

     Una lista de directorios de fuentes, directorios de pruebas y
     nombres de jar pueden especificarse con los parámetros
     ‘#:source-dirs’, ‘#:test-dirs’ y ‘#:jar-names’, respectivamente.
     El directorio de compilación y la clase principal pueden
     especificarse con los parámetros ‘#:compile-dir’ y ‘#:main-class’,
     respectivamente.  Otros parámetros se documentan más adelante.

     Este sistema de construcción es una extensión de ANT-BUILD-SYSTEM,
     pero con las siguientes fases cambiadas:

     ‘build’
          Esta fase llama ‘compile’ en Clojure para compilar los
          archivos de fuentes y ejecuta ‘jar’ para crear archivadores
          jar tanto de archivos de fuentes y compilados de acuerdo con
          las listas de inclusión y exclusión especificadas en
          ‘#:aot-include’ y ‘#:aot-exclude’, respectivamente.  La lista
          de exclusión tiene prioridad sobre la de inclusión.  Estas
          listas consisten en símbolos que representan bibliotecas
          Clojure o la palabra clave especial ‘#:all’ que representa
          todas las bibliotecas encontradas en los directorios de
          fuentes.  El parámetro ‘#:omit-source?’ determina si las
          fuentes deben incluirse en los archivadores jar.

     ‘check’
          Esta fase ejecuta las pruebas de acuerdo a las listas de
          inclusión y exclusión especificadas en ‘#:test-include’ y
          ‘#:test-exclude’, respectivamente.  Sus significados son
          análogos a los de ‘#:aot-include’ y ‘#:aot-exclude’, excepto
          que la palabra clave especial ‘#:all’ designa ahora a todas
          las bibliotecas Clojure encontradas en los directorios de
          pruebas.  El parámetro ‘#:tests?’ determina si se deben
          ejecutar las pruebas.

     ‘install’
          Esta fase instala todos los archivadores jar construidos
          previamente.

     Además de las previas, este sistema de construcción contiene una
     fase adicional:

     ‘install-doc’
          Esta fase instala todos los archivos de nivel superior con un
          nombre que corresponda con %DOC-REGEX.  Una expresión regular
          diferente se puede especificar con el parámetro ‘#:doc-regex’.
          Todos los archivos dentro (recursivamente) de los directorios
          de documentación especificados en ‘#:doc-dirs’ se instalan
          también.

 -- Variable Scheme: cmake-build-system
     Esta variable se exporta en ‘(guix build-system cmake)’.
     Implementa el procedimiento de construcción para paquetes que usen
     la herramienta de construcción CMake (https://www.cmake.org).

     Automáticamente añade el paquete ‘cmake’ al conjunto de entradas.
     El paquete usado se puede especificar con el parámetro ‘#:cmake’.

     El parámetro ‘#:configure-flags’ se toma como una lista de opciones
     a pasar a ‘cmake’.  El parámetro ‘#:build-type’ especifica en
     términos abstractos las opciones pasadas al compilador; su valor
     predeterminado es ‘"RelWithDebInfo"’ (quiere decir “modo de entrega
     con información de depuración”), lo que aproximadamente significa
     que el código se compila con ‘-O2 -g’, lo cual es el caso
     predeterminado en paquetes basados en Autoconf.

 -- Variable Scheme: dune-build-system
     Esta variable se exporta en ‘(guix build-system dune)’.  Permite la
     construcción de paquetes mediante el uso de Dune
     (https://dune.build/), una herramienta de construcción para el
     lenguaje de programación OCaml.  Se implementa como una extensión
     de ‘ocaml-build-system’ que se describe a continuación.  Como tal,
     se pueden proporcionar los parámetros ‘#:ocaml’ y ‘#:findlib’ a
     este sistema de construcción.

     Automáticamente añade el paquete ‘dune’ al conjunto de entradas.
     El paquete usado se puede especificar con el parámetro ‘#:dune’.

     No existe una fase ‘configure’ debido a que los paquetes dune no
     necesitan ser configurados típicamente.  El parámetro
     ‘#:build-flags’ se toma como una lista de opciones proporcionadas a
     la orden ‘dune’ durante la construcción.

     El parámetro ‘#:jbuild?’ puede proporcionarse para usar la orden
     ‘jbuild’ en vez de la más reciente ‘dune’ durante la construcción
     de un paquete.  Su valor predeterminado es ‘#f’.

     El parámetro ‘#:package’ puede proporcionarse para especificar un
     nombre de paquete, lo que resulta útil cuando un paquete contiene
     múltiples paquetes y únicamente quiere construir uno de ellos.  Es
     equivalente a proporcionar el parámetro ‘-p’ a ‘dune’.

 -- Scheme variable: elm-build-system
     This variable is exported by ‘(guix build-system elm)’.  It
     implements a build procedure for Elm (https://elm-lang.org)
     packages similar to ‘elm install’.

     The build system adds an Elm compiler package to the set of inputs.
     The default compiler package (currently ‘elm-sans-reactor’) can be
     overridden using the ‘#:elm’ argument.  Additionally, Elm packages
     needed by the build system itself are added as implicit inputs if
     they are not already present: to suppress this behavior, use the
     ‘#:implicit-elm-package-inputs?’ argument, which is primarily
     useful for bootstrapping.

     The ‘"dependencies"’ and ‘"test-dependencies"’ in an Elm package’s
     ‘elm.json’ file correspond to ‘propagated-inputs’ and ‘inputs’,
     respectively.

     Elm requires a particular structure for package names: *note
     Paquetes Elm:: for more details, including utilities provided by
     ‘(guix build-system elm)’.

     There are currently a few noteworthy limitations to
     ‘elm-build-system’:

        • The build system is focused on “packages” in the Elm sense of
          the word: Elm “projects” which declare ‘{ "type": "package" }’
          in their ‘elm.json’ files.  Using ‘elm-build-system’ to build
          Elm “applications” (which declare ‘{ "type": "application" }’)
          is possible, but requires ad-hoc modifications to the build
          phases.  For examples, see the definitions of the
          ‘elm-todomvc’ example application and the ‘elm’ package itself
          (because the front-end for the ‘elm reactor’ command is an Elm
          application).

        • Elm supports multiple versions of a package coexisting
          simultaneously under ‘ELM_HOME’, but this does not yet work
          well with ‘elm-build-system’.  This limitation primarily
          affects Elm applications, because they specify exact versions
          for their dependencies, whereas Elm packages specify supported
          version ranges.  As a workaround, the example applications
          mentioned above use the ‘patch-application-dependencies’
          procedure provided by ‘(guix build elm-build-system)’ to
          rewrite their ‘elm.json’ files to refer to the package
          versions actually present in the build environment.
          Alternatively, Guix package transformations (*note Definición
          de variantes de paquetes::) could be used to rewrite an
          application’s entire dependency graph.

        • We are not yet able to run tests for Elm projects because
          neither ‘elm-test-rs’
          (https://github.com/mpizenberg/elm-test-rs) nor the
          Node.js-based ‘elm-test’
          (https://github.com/rtfeldman/node-test-runner) runner has
          been packaged for Guix yet.

 -- Variable Scheme: go-build-system
     Esta variable se exporta en ‘(guix build-system go)’.  Implementa
     el procedimiento de construcción para paquetes Go usando los
     mecanismos de construcción de Go
     (https://golang.org/cmd/go/#hdr-Compile_packages_and_dependencies)
     estándares.

     Se espera que la usuaria proporcione un valor para el parámetro
     ‘#:import-path’ y, en algunos caso, ‘#:unpack-path’.  La ruta de
     importación (https://golang.org/doc/code.html#ImportPaths)
     corresponde a la ruta del sistema de archivos esperada por los
     guiones de construcción del paquete y los paquetes a los que hace
     referencia, y proporciona una forma de hacer referencia a un
     paquete Go unívocamente.  Está basado típicamente en una
     combinación de la URI remota del paquete de archivos de fuente y la
     estructura jerárquica del sistema de archivos.  En algunos casos,
     necesitará desempaquetar el código fuente del paquete en una
     estructura de directorios diferente a la indicada en la ruta de
     importación, y ‘#:unpack-path’ debe usarse en dichos casos.

     Los paquetes que proporcionan bibliotecas Go deben instalar su
     código fuente en la salida de la construcción.  El parámetro
     ‘#:install-source?’, cuyo valor por defecto es ‘#t’, controla si se
     instalará o no el código fuente.  Puede proporcionarse ‘#f’ en
     paquetes que proporcionan únicamente archivos ejecutables.

     Packages can be cross-built, and if a specific architecture or
     operating system is desired then the keywords ‘#:goarch’ and
     ‘#:goos’ can be used to force the package to be built for that
     architecture and operating system.  The combinations known to Go
     can be found in their documentation
     ("https://golang.org/doc/install/source#environment").

 -- Variable Scheme: glib-or-gtk-build-system
     Esta variable se exporta en ‘(guix build-system glib-or-gtk)’.
     Está pensada para usarse con paquetes que usan GLib o GTK+.

     Este sistema de construcción añade las dos fases siguientes a las
     definidas en GNU-BUILD-SYSTEM:

     ‘glib-or-gtk-wrap’
          La fase ‘glib-or-gtk-wrap’ se asegura de que los programas en
          ‘bin/’ son capaces de encontrar los “esquemas” GLib y los
          módulos GTK+
          (https://developer.gnome.org/gtk3/stable/gtk-running.html).
          Esto se consigue recubriendo los programas en guiones de
          lanzamiento que proporcionan valores apropiados para las
          variables de entorno ‘XDG_DATA_DIRS’ y ‘GTK_PATH’.

          Es posible excluir salidas específicas del paquete del proceso
          de recubrimiento enumerando sus nombres en el parámetro
          ‘#:glib-org-gtk-wrap-excluded-outputs’.  Esto es útil cuando
          se sabe que una salida no contiene binarios GLib o GTK+, y
          cuando empaquetar gratuitamente añadiría una dependencia de
          dicha salida en GLib y GTK+.

     ‘glib-or-gtk-compile-schemas’
          La fase ‘glib-or-gtk-compile-schemas’ se asegura que todos los
          esquemas GSettings
          (https://developer.gnome.org/gio/stable/glib-compile-schemas.html)
          o GLib se compilan.  La compilación la realiza el programa
          ‘glib-compile-schemas’.  Lo proporciona el paquete ‘glib:bin’
          que se importa automáticamente por el sistema de construcción.
          El paquete ‘glib’ que proporciona ‘glib-compile-schemas’ puede
          especificarse con el parámetro ‘#:glib’.

     Ambas fases se ejecutan tras la fase ‘install’.

 -- Variable Scheme: guile-build-system
     Este sistema de construcción es para paquetes Guile que consisten
     exclusivamente en código Scheme y son tan simples que no tienen ni
     siquiera un archivo Makefile, menos un guión ‘configure’.  Compila
     código Scheme usando ‘guild compile’ (*note (guile)Compilation::) e
     instala los archivos ‘.scm’ y ‘.go’ en el lugar correcto.  También
     instala documentación.

     Este sistema de construcción permite la compilación cruzada usando
     la opción ‘--target’ de ‘guild compile’.

     Los paquetes construidos con ‘guile-build-system’ deben
     proporcionar un paquete Guile en su campo ‘native-inputs’.

 -- Variable Scheme: julia-build-system
     This variable is exported by ‘(guix build-system julia)’.  It
     implements the build procedure used by julia
     (https://julialang.org/) packages, which essentially is similar to
     running ‘julia -e 'using Pkg; Pkg.add(package)'’ in an environment
     where ‘JULIA_LOAD_PATH’ contains the paths to all Julia package
     inputs.  Tests are run by calling ‘/test/runtests.jl’.

     The Julia package name and uuid is read from the file
     ‘Project.toml’.  These values can be overridden by passing the
     argument ‘#:julia-package-name’ (which must be correctly
     capitalized) or ‘#:julia-package-uuid’.

     Julia packages usually manage their binary dependencies via
     ‘JLLWrappers.jl’, a Julia package that creates a module (named
     after the wrapped library followed by ‘_jll.jl’.

     To add the binary path ‘_jll.jl’ packages, you need to patch the
     files under ‘src/wrappers/’, replacing the call to the macro
     ‘JLLWrappers.@generate_wrapper_header’, adding as a second argument
     containing the store path the binary.

     As an example, in the MbedTLS Julia package, we add a build phase
     (*note Fases de construcción::) to insert the absolute file name of
     the wrapped MbedTLS package:

          (add-after 'unpack 'override-binary-path
            (lambda* (#:key inputs #:allow-other-keys)
              (for-each (lambda (wrapper)
                          (substitute* wrapper
                            (("generate_wrapper_header.*")
                             (string-append
                              "generate_wrapper_header(\"MbedTLS\", \""
                              (assoc-ref inputs "mbedtls-apache") "\")\n"))))
                        ;; There's a Julia file for each platform, override them all.
                        (find-files "src/wrappers/" "\\.jl$"))))

     Some older packages that aren’t using ‘Project.toml’ yet, will
     require this file to be created, too.  It is internally done if the
     arguments ‘#:julia-package-name’ and ‘#:julia-package-uuid’ are
     provided.

 -- Variable Scheme: maven-build-system
     Esta variable se exporta en ‘(guix build-system maven)’.
     Implementa un procedimiento de construcción para paquetes basados
     en Maven (https://maven.apache.org).  Maven es una herramienta para
     Java de gestión de dependencias y ciclo de vida.  Las usuarias de
     Maven especifican las dependencias y módulos en un archivo
     ‘pom.xml’ que Maven lee.  Cuando Maven no dispone de una de dichas
     dependencias o módulos en su repositorio, las descarga y las usa
     para construir el paquete.

     El sistema de compilación de maven se asegura de que maven no
     intentará descargar ninguna dependencia ejecutándo maven en modo
     sin conexión.  Maven fallará si falta alguna dependencia.  Antes de
     ejecutar Maven, el archivo ‘pom.xml’ (y los subproyectos) se
     modifican para especificar la versión de las dependencias y módulos
     que corresponden a las versiones disponibles en el entorno de
     construcción de guix.  Las dependencias y los módulos se deben
     instalar en un repositorio de maven ad hoc en ‘lib/m2’, y se
     enlazan un repositorio real antes de que se ejecute maven.  Se le
     indica a Maven que use ese repositorio para la construcción e
     instale los artefactos generados allí.  Los archivos cambiados se
     copian del directorio ‘lib/m2’ a la salida del paquete.

     Puede especificar un archivo ‘pom.xml’ con el parámetro
     ‘#:pom-file’, o dejar al sistema de construcción usar el archivo
     predeterminado ‘pom.xml’ en las fuentes.

     En caso de que necesite especificar la versión de una dependencia
     manualmente puede usar el parámetro ‘#:local-packages’.  Toma como
     valor una lista asociativa donde la clave es el valor del campo
     “groupId” del paquete y su valor es una lista asociativa donde la
     clave es el campo “artifactId” del paquete y su valor la versión
     que quiere forzar en vez de la que se encuentra en ‘pom.xml’.

     Algunos paquetes usan dependencias o módulos que no son útiles en
     tiempo de ejecución ni en tiempo de construcción en Guix.  Puede
     modificar el archivo ‘pom.xml’ para eliminarlos usando el parámetro
     ‘#:exclude’.  Su valor es una lista asociativa donde la clave es el
     valor del campo “groupId” del módulo o dependencia que quiere
     eliminar, y su valor es una lista de valores del campo “artifactId”
     que se eliminarán.

     Puede usar valores distintos para los paquetes ‘jdk’ y ‘maven’ con
     el parámetro correspondiente, ‘#:jdk’ y ‘#:maven’.

     El parámetro ‘#:maven-plugins’ es una lista de módulos de maven
     usados durante la construcción, con el mismo formato que el campo
     ‘inputs’ de la declaración del paquete.  Su valor predeterminado es
     ‘(default-maven-plugins)’ que también se exporta.

 -- Scheme Variable: minetest-mod-build-system
     This variable is exported by ‘(guix build-system minetest)’.  It
     implements a build procedure for Minetest
     (https://www.minetest.net) mods, which consists of copying Lua
     code, images and other resources to the location Minetest searches
     for mods.  The build system also minimises PNG images and verifies
     that Minetest can load the mod without errors.

 -- Variable Scheme: minify-build-system
     Esta variable se exporta en ‘(guix build-system minify)’.
     Implementa un procedimiento de minificación para paquetes
     JavaScript simples.

     Añade ‘uglify-js’ al conjunto de entradas y lo utiliza para
     comprimir todos los archivos JavaScript en el directorio ‘src’.  Un
     paquete de minificación diferente puede especificarse con el
     parámetro ‘#:uglify-js’, pero se espera que el paquete escriba el
     código minificado en la salida estándar.

     Cuando los archivos JavaScript de entrada no se encuentran en el
     directorio ‘src’, el parámetro ‘#:javascript-files’ puede usarse
     para especificar una lista de nombres de archivo que proporcionar
     al minificador.

 -- Variable Scheme: ocaml-build-system
     Esta variable se exporta en ‘(guix build-system ocaml)’.
     Implementa un procedimiento de construcción para paquetes OCaml
     (https://ocaml.org), que consiste en seleccionar el conjunto
     correcto de órdenes a ejecutar para cada paquete.  Los paquetes
     OCaml pueden esperar la ejecución de muchas ordenes diferentes.
     Este sistema de construcción probará algunas de ellas.

     Cuando el paquete tiene un archivo ‘setup.ml’ presente en el nivel
     superior, se ejecuta ‘ocaml setup.ml -configure’, ‘ocaml setup.ml
     -build’ y ‘ocaml setup.ml -install’.  El sistema de construcción
     asumirá que este archivo se generó con
     <http://oasis.forge.ocamlcore.org/ OASIS> y se encargará de
     establecer el prefijo y la activación de las pruebas si no se
     desactivaron.  Puede pasar opciones de configuración y construcción
     con ‘#:configure-flags’ y ‘#:build-flags’, respectivamente.  El
     parámetro ‘#:test-flags’ puede usarse para cambiar el conjunto de
     opciones usadas para activar las pruebas.  El parámetro
     ‘#:use-make?’ puede usarse para ignorar este sistema en las fases
     de construcción e instalación.

     Cuando el paquete tiene un archivo ‘configure’, se asume que es un
     guión de configuración hecho a mano que necesita un formato de
     parámetros diferente a los del sistema ‘gnu-build-system’.  Puede
     añadir más opciones con el parámetro ‘#:configure-flags’.

     Cuando el paquete tiene un archivo ‘Makefile’ (o ‘#:use-make?’ es
     ‘#t’), será usado y se pueden proporcionar más opciones para las
     fases de construcción y e instalación con el parámetro
     ‘#:make-flags’.

     Por último, algunos paquetes no tienen estos archivos y usan unas
     localizaciones de algún modo estándares para su sistema de
     construcción.  En este caso, el sistema de construcción ejecutará
     ‘ocaml pkg/pkg.ml’ o ‘ocaml pkg/build.ml’ y se hará cargo de
     proporcionar la ruta del módulo findlib necesario.  Se pueden pasar
     opciones adicionales con el parámetro ‘#:build-flags’.  De la
     instalación se hace cargo ‘opam-installer’.  En este caso, el
     paquete ‘opam’ debe añadirse al campo ‘native-inputs’ de la
     definición del paquete.

     Fíjese que la mayoría de los paquetes OCaml asumen su instalación
     en el mismo directorio que OCaml, lo que no es el comportamiento
     deseado en guix.  En particular, tratarán de instalar archivos
     ‘.so’ en su directorio de módulos, lo que normalmente es aceptable
     puesto que está bajo el directorio del compilador de OCaml.  No
     obstante, en guix estas bibliotecas no se pueden instalar ahí, por
     lo que se usa ‘CAML_LD_LIBRARY_PATH’.  Esta variable apunta a
     ‘lib/ocaml/site-lib/stubslibs’ y allí es donde se deben instalar
     las bibliotecas ‘.so’.

 -- Variable Scheme: python-build-system
     Esta variable se exporta en ‘(guix build-system python)’.
     Implementa el procedimiento más o menos estándar de construcción
     usado por paquetes Python, que consiste en la ejecución de ‘python
     setup.py build’ y ‘python setup.py install
     --prefix=/gnu/store/...’.

     For packages that install stand-alone Python programs under ‘bin/’,
     it takes care of wrapping these programs so that their
     ‘GUIX_PYTHONPATH’ environment variable points to all the Python
     libraries they depend on.

     Se puede especificar el paquete Python usado para llevar a cabo la
     construcción con el parámetro ‘#:python’.  Esta es habitualmente
     una forma de forzar la construcción de un paquete para una versión
     específica del intérprete Python, lo que puede ser necesario si el
     paquete es compatible únicamente con una versión del intérprete.

     De manera predeterminada guix llama a ‘setup.py’ bajo el control de
     ‘setuptools’ de manera similar a lo realizado por ‘pip’.  Algunos
     paquetes no son compatibles con setuptools (y pip), por lo que
     puede desactivar esta configuración estableciendo el parámetro
     ‘#:use-setuptools’ a ‘#f’.

     If a ‘"python"’ output is available, the package is installed into
     it instead of the default ‘"out"’ output.  This is useful for
     packages that include a Python package as only a part of the
     software, and thus want to combine the phases of
     ‘python-build-system’ with another build system.  Python bindings
     are a common usecase.

 -- Scheme Variable: pyproject-build-system
     This is a variable exported by ‘guix build-system pyproject’.  It
     is based on PYTHON-BUILD-SYSTEM, and adds support for
     ‘pyproject.toml’ and PEP 517 (https://peps.python.org/pep-0517/).
     It also supports a variety of build backends and test frameworks.

     The API is slightly different from PYTHON-BUILD-SYSTEM:
        • ‘#:use-setuptools?’ and ‘#:test-target’ is removed.
        • ‘#:build-backend’ is added.  It defaults to ‘#false’ and will
          try to guess the appropriate backend based on
          ‘pyproject.toml’.
        • ‘#:test-backend’ is added.  It defaults to ‘#false’ and will
          guess an appropriate test backend based on what is available
          in package inputs.
        • ‘#:test-flags’ is added.  The default is ‘'()’.  These flags
          are passed as arguments to the test command.  Note that flags
          for verbose output is always enabled on supported backends.

     It is considered “experimental” in that the implementation details
     are not set in stone yet, however users are encouraged to try it
     for new Python projects (even those using ‘setup.py’).  The API is
     subject to change, but any breaking changes in the Guix channel
     will be dealt with.

     Eventually this build system will be deprecated and merged back
     into PYTHON-BUILD-SYSTEM, probably some time in 2024.

 -- Variable Scheme: perl-build-system
     Esta variable se exporta en ‘(guix build-system perl)’.  Implementa
     el procedimiento de construcción estándar para paquetes Perl, lo
     que o bien consiste en la ejecución de ‘perl Build.PL
     --prefix=/gnu/store/...’, seguido de ‘Build’ y ‘Build install’; o
     en la ejecución de ‘perl Makefile.PL PREFIX=/gnu/store/...’,
     seguida de ‘make’ y ‘make install’, dependiendo de si ‘Build.PL’ o
     ‘Makefile.PL’ están presentes en la distribución del paquete.  El
     primero tiene preferencia si existen tanto ‘Build.PL’ como
     ‘Makefile.PL’ en la distribución del paquete.  Esta preferencia
     puede ser invertida mediante la especificación del valor ‘#t’ en el
     parámetro ‘#:make-maker?’.

     La invocación inicial de ‘perl Makefile.PL’ o ‘perl Build.PL’ pasa
     a su vez las opciones especificadas por los parámetros
     ‘#:make-maker-flags’ o ‘#:module-build-flags’, respectivamente.

     El paquete Perl usado puede especificarse con ‘#:perl’.

 -- Scheme Variable: renpy-build-system
     This variable is exported by ‘(guix build-system renpy)’.  It
     implements the more or less standard build procedure used by Ren’py
     games, which consists of loading ‘#:game’ once, thereby creating
     bytecode for it.

     It further creates a wrapper script in ‘bin/’ and a desktop entry
     in ‘share/applications’, both of which can be used to launch the
     game.

     Which Ren’py package is used can be specified with ‘#:renpy’.
     Games can also be installed in outputs other than “out” by using
     ‘#:output’.

 -- Variable Scheme: qt-build-system
     Esta variable se exporta en ‘(guix build-system qt)’.  Está pensado
     para usarse con aplicaciones que usen Qt o KDE.

     Este sistema de construcción añade las dos fases siguientes a las
     definidas en CMAKE-BUILD-SYSTEM:

     ‘check-setup’
          La fase ‘check-setup’ prepara el entorno para la ejecución de
          las comprobaciones usadas habitualmente por los programas de
          pruebas de Qt.  Por ahora únicamente proporciona valor a
          algunas variables de entorno: ‘QT_QPA_PLATFORM=offscreen’,
          ‘DBUS_FATAL_WARNINGS=0’ y ‘CTEST_OUTPUT_ON_FAILURE=1’.

          Esta fase se añade previamente a la fase ‘check’.  Es una fase
          separada para facilitar el ajuste si fuese necesario.

     ‘qt-wrap’
          La fase ‘qt-wrap’ busca las rutas de módulos de Qt5, las rutas
          de QML y algunas rutas XDG en las entradas y la salida.  En
          caso de que alguna ruta se encuentra, todos los programas en
          los directorios ‘bin/’, ‘sbin/’, ‘libexec/’ y ‘lib/libexec/’
          de la salida se envuelven en guiones que definen las variables
          de entorno necesarias.

          Es posible excluir salidas específicas del paquete del proceso
          de recubrimiento enumerando sus nombres en el parámetro
          ‘#:qt-wrap-excluded-outputs’.  Esto es útil cuando se sabe que
          una salida no contiene binarios que usen Qt, y cuando
          empaquetar gratuitamente añadiría una dependencia de dicha
          salida en Qt.

          Ambas fases se añaden tras la fase ‘install’.

 -- Variable Scheme: r-build-system
     Esta variable se exporta en ‘(guix build-system r)’.  Implementa el
     procedimiento de construcción usados por paquetes R
     (https://r-project.org), lo que esencialmente es poco más que la
     ejecución de ‘R CMD INSTALL --library=/gnu/store/...’ en un entorno
     donde ‘R_LIBS_SITE’ contiene las rutas de todos los paquetes R de
     entrada.  Las pruebas se ejecutan tras la instalación usando la
     función R ‘tools::testInstalledPackage’.

 -- Variable Scheme: rakudo-build-system
     This variable is exported by ‘(guix build-system rakudo)’.  It
     implements the build procedure used by Rakudo (https://rakudo.org/)
     for Perl6 (https://perl6.org/) packages.  It installs the package
     to ‘/gnu/store/.../NAME-VERSION/share/perl6’ and installs the
     binaries, library files and the resources, as well as wrap the
     files under the ‘bin/’ directory.  Tests can be skipped by passing
     ‘#f’ to the ‘tests?’ parameter.

     El paquete rakudo en uso puede especificarse con ‘rakudo’.  El
     paquete perl6-tap-harness en uso durante las pruebas puede
     especificarse con ‘#:prove6’ o eliminarse proporcionando ‘#f’ al
     parámetro ‘with-prove6?’.  El paquete perl6-zef en uso durante las
     pruebas e instalación puede especificarse con ‘#:zef’ o eliminarse
     proporcionando ‘#f’ al parámetro ‘with-zef?’.

 -- Scheme Variable: rebar-build-system
     This variable is exported by ‘(guix build-system rebar)’.  It
     implements a build procedure around rebar3 (https://rebar3.org), a
     build system for programs written in the Erlang language.

     It adds both ‘rebar3’ and the ‘erlang’ to the set of inputs.
     Different packages can be specified with the ‘#:rebar’ and
     ‘#:erlang’ parameters, respectively.

     This build system is based on ‘gnu-build-system’, but with the
     following phases changed:

     ‘unpack’
          This phase, after unpacking the source like the
          ‘gnu-build-system’ does, checks for a file ‘contents.tar.gz’
          at the top-level of the source.  If this file exists, it will
          be unpacked, too.  This eases handling of package hosted at
          <https://hex.pm/>, the Erlang and Elixir package repository.

     ‘bootstrap’
     ‘configure’
          There are no ‘bootstrap’ and ‘configure’ phase because erlang
          packages typically don’t need to be configured.

     ‘build’
          This phase runs ‘rebar3 compile’ with the flags listed in
          ‘#:rebar-flags’.

     ‘check’
          Unless ‘#:tests? #f’ is passed, this phase runs ‘rebar3
          eunit’, or some other target specified with ‘#:test-target’,
          with the flags listed in ‘#:rebar-flags’,

     ‘install’
          This installs the files created in the default profile, or
          some other profile specified with ‘#:install-profile’.

 -- Variable Scheme: texlive-build-system
     Esta variable se exporta en ‘(guix build-system texlive)’.  Se usa
     para construir paquetes TeX en modo de procesamiento de lotes con
     el motor especificado.  El sistema de construcción proporciona
     valor a la variable ‘TEXINPUTS’ para encontrar todos los archivos
     de fuentes TeX en las entradas.

     Por defecto ejecuta ‘luatex’ en todos los archivos que terminan en
     ‘ins’.  Un motor y formato diferente puede especificarse con el
     parámetro ‘#:tex-format’.  Los diferentes objetivos de construcción
     pueden especificarse con el parámetro ‘#:build-targets’, que espera
     una lista de nombres de archivo.  El sistema de construcción añade
     únicamente ‘texlive-bin’ y ‘texlive-latex-base’ (ambos desde ‘(gnu
     packages tex)’ a las entradas.  Ambos pueden forzarse con los
     parámetros ‘#:texlive-bin’ y ‘#:texlive-latex-base’
     respectivamente.

     El parámetro ‘#:tex-directory’ le dice al sistema de construcción
     dónde instalar los archivos construidos bajo el árbol texmf.

 -- Variable Scheme: ruby-build-system
     Esta variable se exporta en ‘(guix build-system ruby)’.  Implementa
     el procedimiento de construcción de RubyGems usado por los paquetes
     Ruby, que implica la ejecución de ‘gem build’ seguida de ‘gem
     install’.

     El campo ‘source’ de un paquete que usa este sistema de
     construcción típicamente se refiere a un archivo gem, ya que este
     es el formato usado por las desarrolladoras Ruby cuando publican su
     software.  El sistema de construcción desempaqueta el archivo gem,
     potencialmente parchea las fuentes, ejecuta la batería de pruebas,
     vuelve a empaquetar el archivo gem y lo instala.  Adicionalmente,
     se puede hacer referencia a directorios y archivadores tar para
     permitir la construcción de archivos gem no publicados desde Git o
     un archivador tar de publicación de fuentes tradicional.

     Se puede especificar el paquete Ruby usado mediante el parámetro
     ‘#:ruby’.  Una lista de opciones adicionales pueden pasarse a la
     orden ‘gem’ en el parámetro ‘#:gem-flags’.

 -- Variable Scheme: waf-build-system
     Esta variable se exporta en ‘(guix build-system waf)’.  Implementa
     un procedimiento de construcción alrededor del guión ‘waf’.  Las
     fases comunes—‘configure’, ‘build’ y ‘install’—se implementan
     pasando sus nombres como parámetros al guión ‘waf’.

     El guión ‘waf’ es ejecutado por el intérprete Python.  El paquete
     Python usado para la ejecución puede ser especificado con el
     parámetro ‘#:python’.

 -- Variable Scheme: scons-build-system
     Esta variable se exporta en ‘(guix build-system scons)’.
     Implementa en procedimiento de construcción usado por la
     herramienta de construcción de software SCons.  Este sistema de
     construcción ejecuta ‘scons’ para construir el paquete, ‘scons
     test’ para ejecutar las pruebas y después ‘scons install’ para
     instalar el paquete.

     Las opciones adicionales a pasar a ‘scons’ se pueden especificar
     con el parámetro ‘#:scons-flags’.  Los objetivos predeterminados de
     construcción (build) e instalación (install) pueden modificarse con
     ‘#:build-targets’ y ‘#:install-targets’ respectivamente.  La
     versión de Python usada para ejecutar SCons puede especificarse
     seleccionando el paquete SCons apropiado con el parámetro
     ‘#:scons’.

 -- Variable Scheme: haskell-build-system
     Esta variable se exporta en ‘(guix build-system haskell)’.
     Implementa el procedimiento de construcción Cabal usado por
     paquetes Haskell, el cual implica la ejecución de ‘runhaskell
     Setup.hs configure --prefix=/gnu/store/...’ y ‘runhaskell Setup.hs
     build’.  En vez de instalar el paquete ejecutando ‘runhaskell
     Setup.hs install’, para evitar el intento de registro de
     bibliotecas en el directorio de solo-lectura del compilador en el
     almacén, el sistema de construcción usa ‘runhaskell Setup.hs copy’,
     seguido de ‘runhaskell Setup.hs register’.  Además, el sistema de
     construcción genera la documentación del paquete ejecutando
     ‘runhaskell Setup.hs haddock’, a menos que se pasase ‘#:haddock?
     #f’.  Parámetros opcionales de Haddock pueden proporcionarse con la
     ayuda del parámetro ‘#:haddock-flags’.  Si el archivo ‘Setup.hs’ no
     es encontrado, el sistema de construcción busca ‘Setup.lhs’ a su
     vez.

     El compilador Haskell usado puede especificarse con el parámetro
     ‘#:haskell’ cuyo valor predeterminado es ‘ghc’.

 -- Variable Scheme: dub-build-system
     Esta variable se exporta en ‘(guix build-system dub)’.  Implementa
     el procedimiento de construcción Dub usado por los paquetes D, que
     implica la ejecución de ‘dub build’ y ‘dub run’.  La instalación se
     lleva a cabo con la copia manual de los archivos.

     El compilador D usado puede ser especificado con el parámetro
     ‘#:ldc’ cuyo valor predeterminado es ‘ldc’.

 -- Variable Scheme: emacs-build-system
     Esta variable se exporta en ‘(guix build-system emacs)’.
     Implementa un procedimiento de instalación similar al propio
     sistema de empaquetado de Emacs (*note (emacs)Packages::).

     Primero crea el archivo ‘PAQUETE-autoloads.el’, tras lo que compila
     todos los archivos Emacs Lisp.  De manera diferente al sistema de
     paquetes de Emacs, los archivos de documentación Info se mueven al
     directorio estándar de documentación y se borra el archivo ‘dir’.
     Los archivos del paquete Elisp se instalan directamente en
     ‘share/emacs/site-lisp’.

 -- Variable Scheme: font-build-system
     Esta variable se exporta en ‘(guix build-system font)’.  Implementa
     un procedimiento de instalación para paquetes de fuentes donde las
     proveedoras originales proporcionan archivos de tipografía
     TrueType, OpenType, etc. precompilados que simplemente necesitan
     copiarse en su lugar.  Copia los archivos de tipografías a las
     localizaciones estándar en el directorio de salida.

 -- Variable Scheme: meson-build-system
     Esta variable se exporta en ‘(guix build-system meson)’.
     Implementa el procedimiento de construcción para paquetes que usan
     Meson (https://mesonbuild.com) como su sistema de construcción.

     It adds both Meson and Ninja (https://ninja-build.org/) to the set
     of inputs, and they can be changed with the parameters ‘#:meson’
     and ‘#:ninja’ if needed.

     Este sistema de construcción es una extensión de GNU-BUILD-SYSTEM,
     pero con las siguientes fases cambiadas por otras específicas para
     Meson:

     ‘configure’
          Esta fase ejecuta ‘meson’ con las opciones especificadas en
          ‘#:configure-flags’.  La opción ‘--buildtype’ recibe el valor
          ‘debugoptimized’ excepto cuando se especifique algo distinto
          en ‘#:build-type’.

     ‘build’
          Esta fase ejecuta ‘ninja’ para construir el paquete en
          paralelo por defecto, pero esto puede cambiarse con
          ‘#:parallel-build?’.

     ‘check’
          The phase runs ‘meson test’ with a base set of options that
          cannot be overridden.  This base set of options can be
          extended via the ‘#:test-options’ argument, for example to
          select or skip a specific test suite.

     ‘install’
          Esta fase ejecuta ‘ninja install’ y no puede cambiarse.

     Aparte de estas, el sistema de ejecución también añade las
     siguientes fases:

     ‘fix-runpath’
          This phase ensures that all binaries can find the libraries
          they need.  It searches for required libraries in
          subdirectories of the package being built, and adds those to
          ‘RUNPATH’ where needed.  It also removes references to
          libraries left over from the build phase by ‘meson’, such as
          test dependencies, that aren’t actually required for the
          program to run.

     ‘glib-or-gtk-wrap’
          Esta fase es la fase proporcionada por
          ‘glib-or-gtk-build-system’, y no está activa por defecto.
          Puede activarse con ‘#:glib-or-gtk’.

     ‘glib-or-gtk-compile-schemas’
          Esta fase es la fase proporcionada por
          ‘glib-or-gtk-build-system’, y no está activa por defecto.
          Puede activarse con ‘#:glib-or-gtk’.

 -- Variable Scheme: linux-module-build-system
     LINUX-MODULE-BUILD-SYSTEM permite la construcción de módulos del
     núcleo Linux.

     Este sistema de construcción es una extensión de GNU-BUILD-SYSTEM,
     pero con las siguientes fases cambiadas:

     ‘configure’
          Esta fase configura el entorno de modo que el Makefile del
          núcleo Linux pueda usarse para la construcción del módulo
          externo del núcleo.

     ‘build’
          Esta fase usa el Makefile del núcleo Linux para construir el
          módulo externo del núcleo.

     ‘install’
          Esta fase usa el Makefile del núcleo Linux para instalar el
          módulo externo del núcleo.

     Es posible y útil especificar el núcleo Linux usado para la
     construcción del módulo (para ello debe usar el parámetro ‘#:linux’
     a través de la forma ‘arguments’ en un paquete que use
     ‘linux-module-build-system’).

 -- Variable Scheme: node-build-system
     Esta variable se exporta en ‘(guix build-system node)’.  Implementa
     el procedimiento de construcción usado por Node.js
     (https://nodejs.org), que implementa una aproximación de la orden
     ‘npm install’, seguida de una orden ‘npm test’.

     El paquete Node.js usado para interpretar las órdenes ‘npm’ puede
     especificarse a través del parámetro ‘#:node’ cuyo valor
     predeterminado es ‘node’.

   Por último, para paquetes que no necesiten nada tan sofisticado se
proporciona un sistema de construcción “trivial”.  Es trivial en el
sentido de que no proporciona prácticamente funcionalidad: no incorpora
entradas implícitas y no tiene una noción de fases de construcción.

 -- Variable Scheme: trivial-build-system
     Esta variable se exporta en ‘(guix build-system trivial)’.

     Este sistema de construcción necesita un parámetro ‘#:builder’.
     Este parámetro debe ser una expresión Scheme que construya la(s)
     salida(s) del paquete—como en ‘build-expression->derivation’ (*note
     ‘build-expression->derivation’: Derivaciones.).

 -- Scheme Variable: channel-build-system
     This variable is exported by ‘(guix build-system channel)’.

     This build system is meant primarily for internal use.  A package
     using this build system must have a channel specification as its
     ‘source’ field (*note Canales::); alternatively, its source can be
     a directory name, in which case an additional ‘#:commit’ argument
     must be supplied to specify the commit being built (a hexadecimal
     string).

     The resulting package is a Guix instance of the given channel,
     similar to how ‘guix time-machine’ would build it.


File: guix.es.info,  Node: Fases de construcción,  Next: Utilidades de construcción,  Prev: Sistemas de construcción,  Up: Interfaz programática

9.6 Fases de construcción
=========================

Prácticamente todos los sistemas de construcción de paquetes implementan
una noción de “fases de construcción”: una secuencia de acciones
ejecutadas por el sistema de construcción, cuando usted construya el
paquete, que conducen a la instalación de su producción en el almacén.
Una excepción notable es el sistema de construcción trivial
‘trivial-build-system’ (*note Sistemas de construcción::).

   As discussed in the previous section, those build systems provide a
standard list of phases.  For ‘gnu-build-system’, the main build phases
are the following:

‘set-paths’
     Define search path environment variables for all the input
     packages, including ‘PATH’ (*note Search Paths::).

‘unpack’
     Extrae el archivador tar de la fuente, y cambia el directorio
     actual al directorio recién extraído.  Si la fuente es realmente un
     directorio, lo copia al árbol de construcción y entra en ese
     directorio.

‘patch-source-shebangs’
     Sustituye secuencias “#!” encontradas al inicio de los archivos de
     fuentes para que hagan referencia a los nombres correctos de
     archivos del almacén.  Por ejemplo, esto cambia ‘#!/bin/sh’ por
     ‘#!/gnu/store/...-bash-4.3/bin/sh’.

‘configure’
     Ejecuta el guión ‘configure’ con algunas opciones predeterminadas,
     como ‘--prefix=/gnu/store/...’, así como las opciones especificadas
     por el parámetro ‘#:configure-flags’.

‘build’
     Ejecuta ‘make’ con la lista de opciones especificadas en
     ‘#:make-flags’.  Si el parámetro ‘#:parallel-build?’ es verdadero
     (por defecto), construye con ‘make -j’.

‘check’
     Ejecuta ‘make check’, u otro objetivo especificado con
     ‘#:test-target’, a menos que se pasase ‘#:tests? #f’.  Si el
     parámetro ‘#:parallel-tests?’ es verdadero (por defecto), ejecuta
     ‘make check -j’.

‘install’
     Ejecuta ‘make install’ con las opciones enumeradas en
     ‘#:make-flags’.

‘patch-shebangs’
     Sustituye las secuencias “#!” en los archivos ejecutables
     instalados.

‘strip’
     Extrae los símbolos de depuración de archivos ELF (a menos que el
     valor de ‘#:strip-binaries?’ sea falso), y los copia a la salida
     ‘debug’ cuando esté disponible (*note Instalación de archivos de
     depuración::).

‘validate-runpath’
     Validate the ‘RUNPATH’ of ELF binaries, unless
     ‘#:validate-runpath?’ is false (*note Sistemas de construcción::).

     This validation step consists in making sure that all the shared
     libraries needed by an ELF binary, which are listed as ‘DT_NEEDED’
     entries in its ‘PT_DYNAMIC’ segment, appear in the ‘DT_RUNPATH’
     entry of that binary.  In other words, it ensures that running or
     using those binaries will not result in a “file not found” error at
     run time.  *Note ‘-rpath’: (ld)Options, for more information on
     ‘RUNPATH’.

   Other build systems have similar phases, with some variations.  For
example, ‘cmake-build-system’ has same-named phases but its ‘configure’
phases runs ‘cmake’ instead of ‘./configure’.  Others, such as
‘python-build-system’, have a wholly different list of standard phases.
All this code runs on the “build side”: it is evaluated when you
actually build the package, in a dedicated build process spawned by the
build daemon (*note Invocación de guix-daemon::).

   Las fases de construcción se representan como listas asociativas o
“alists” (*note (guile)Association Lists::) donde cada clave es un
símbolo que nombra a la fase y el valor asociado es un procedimiento que
acepta un número arbitrario de parámetros.  Por convención, estos
procedimientos reciben información sobre la construcción en forma de
“parámetros que usan palabras clave”, de los cuales pueden hacer uso o
ignorarlos.

   Por ejemplo, esta es la forma en la que ‘(guix build
gnu-build-system)’ define ‘%standard-phases’, la variable que contiene
su lista asociativa de fases de construcción(1):

     ;; Las fases de construcción de 'gnu-build-system'.

     (define* (unpack #:key source #:allow-other-keys)
       ;; Extracción del archivador tar de las fuentes.
       (invoke "tar" "xvf" source))

     (define* (configure #:key outputs #:allow-other-keys)
       ;; Ejecución del guión 'configure'. Instalación de la salida
       ;; en "out".
       (let ((out (assoc-ref outputs "out")))
         (invoke "./configure"
                 (string-append "--prefix=" out))))

     (define* (build #:allow-other-keys)
       ;; Compilación.
       (invoke "make"))

     (define* (check #:key (test-target "check") (tests? #true)
                     #:allow-other-keys)
       ;; Ejecución de la batería de pruebas.
       (if tests?
           (invoke "make" test-target)
           (display "test suite not run\n")))

     (define* (install #:allow-other-keys)
       ;; Instalación de los archivos en el prefijo especificado
       ;; al guión 'configure'.
       (invoke "make" "install"))

     (define %standard-phases
       ;; La lista de las fases estándar (algunas se omiten por
       ;; brevedad). Cada elemento es un par símbolo/procedimiento.
       (list (cons 'unpack unpack)
             (cons 'configure configure)
             (cons 'build build)
             (cons 'check check)
             (cons 'install install)))

   Aquí se muestra como ‘%standard-phases’ se define como una lista de
pares símbolo/procedimiento (*note (guile)Pairs::).  El primer par
asocia el procedimiento ‘unpack’ con el símbolo ‘unpack’—un nombre; el
segundo par define de manera similar la fase ‘configure’, etcétera.
Cuando se construye un paquete que usa ‘gnu-build-system’, con su lista
predeterminada de fases, estas fases se ejecutan de manera secuencial.
Puede ver el nombre de cada fase a su inicio y tras su finalización en
el registro de construcción de los paquetes que construya.

   Echemos un vistazo a los propios procedimientos.  Cada uno se define
con ‘define*’: ‘#:key’ enumera parámetros con palabras clave que el
procedimiento acepta, con la posibilidad de proporcionar un valor
predeterminado, y ‘#:allow-other-keys’ especifica que se ignora
cualquier otra palabra clave en los parámetros (*note (guile)Optional
Arguments::).

   El procedimiento ‘unpack’ utiliza el valor proporcionado al parámetro
‘source’, usado por el sistema de construcción usa para proporcionar el
nombre de archivo del archivador de fuentes (o la copia de trabajo del
sistema de control de versiones), e ignora otros parámetros.  La fase
‘configure’ únicamente tiene en cuenta el parámetro ‘outputs’, una lista
asociativa de nombres de salida de paquetes con su nombre de archivo en
el almacén (*note Paquetes con múltiples salidas::).  Para ello se
extrae el nombre de archivo de ‘out’, la salida predeterminada, y se lo
proporciona a la orden ‘./configure’ como el prefijo de la instalación
(‘./configure --prefix=OUT’), lo que significa que ‘make install’
acabará copiando todos los archivos en dicho directorio (*note
configuration and makefile conventions: (standards)Configuration.).
Tanto ‘build’ como ‘install’ ignoran todos los parámetros.  ‘check’
utiliza el parámetro ‘test-target’, que especifica el nombre del
objetivo del archivo Makefile que debe ejecutarse para ejecutar las
pruebas; se imprime un mensaje y se omiten las pruebas cuando el
parámetro ‘tests?’ tiene falso como valor.

   Se puede cambiar con el parámetro ‘#:phases’ la lista de fases usada
por el sistema de construcción para un paquete en particular.  El cambio
del conjunto de fases de construcción se realiza mediante la
construcción de una nueva lista asociativa basada en la lista asociativa
‘%standard-phases’ descrita previamente.  Esto se puede llevar a cabo
con procedimientos estándar para la manipulación de listas asociativas
como ‘alist-delete’ (*note (guile)SRFI-1 Association Lists::); no
obstante es más conveniente hacerlo con ‘modify-phases’ (*note
‘modify-phases’: Utilidades de construcción.).

   Aquí se encuentra un ejemplo de una definición de paquete que borra
la fase ‘configure’ de ‘%standard-phases’ e inserta una nueva fase antes
de la fase ‘build’, llamada ‘proporciona-prefijo-en-makefile’:

     (define-public example
       (package
         (name "example")
         ;; other fields omitted
         (build-system gnu-build-system)
         (arguments
          '(#:phases (modify-phases %standard-phases
                       (delete 'configure)
                       (add-before 'build 'set-prefix-in-makefile
                         (lambda* (#:key outputs #:allow-other-keys)
                           ;; Modify the makefile so that its
                           ;; 'PREFIX' variable points to "out".
                           (let ((out (assoc-ref outputs "out")))
                             (substitute* "Makefile"
                               (("PREFIX =.*")
                                (string-append "PREFIX = "
                                               out "\n")))))))))))

   La nueva fase insertada se escribe como un procedimiento anónimo,
generado con ‘lambda*’; usa el parámetro ‘outputs’ visto anteriormente.
*Note Utilidades de construcción:: para obtener más información sobre
las funciones auxiliares usadas en esta fase y donde encontrará más
ejemplos de uso de ‘modify-phases’.

   Tenga en cuenta que las fases de construcción son código que se
evalúa cuando se realiza la construcción real del paquete.  Esto explica
por qué la expresión ‘modify-phases’ al completo se encuentra escapada
(viene precedida de ‘'’, un apóstrofe): se ha “preparado” para una
ejecución posterior.  *Note Expresiones-G:: para obener una explicación
sobre esta preparación del código para las distintas fases de ejecución
y los distintos “estratos de código” implicados.

   ---------- Footnotes ----------

   (1) Presentamos una visión simplificada de las fases de dichas
construcción, ¡eche un vistazo al módulo ‘(guix build gnu-build-system)’
para ver todos los detalles!


File: guix.es.info,  Node: Utilidades de construcción,  Next: Search Paths,  Prev: Fases de construcción,  Up: Interfaz programática

9.7 Utilidades de construcción
==============================

En cuanto empiece a escribir definiciones de paquete no-triviales (*note
Definición de paquetes::) u otras acciones de construcción (*note
Expresiones-G::), es probable que empiece a buscar funciones auxiliares
parecidas a las habituales en el intérprete de ordenes—creación de
directorios, borrado y copia recursiva de archivos, manipulación de
fases de construcción, etcétera.  El módulo ‘(guix build utils)’
proporciona dichos procedimientos auxiliares.

   La mayoría de sistemas de construcción cargan ‘(guix build utils)’
(*note Sistemas de construcción::).  Por tanto, cuando construya fases
de construcción personalizadas para sus definiciones de paquetes,
habitualmente puede asumir que dichos procedimientos ya han sido
incorporados al ámbito de ejecución.

   Cuando escriba G-expressions, puede importar ‘(guix build utils)’ en
el “lado de la construcción” mediante el uso ‘with-imported-modules’ e
importandolos al ámbito actual con la forma sintáctica ‘use-modules’
(*note (guile)Using Guile Modules::):

     (with-imported-modules '((guix build utils))  ; Se importa.
       (computed-file "empty-tree"
                      #~(begin
                          ;; Se añade al ámbito actual.
                          (use-modules (guix build utils))

                          ;; Se usa su procedimiento 'mkdir-p'.
                          (mkdir-p (string-append #$output "/a/b/c")))))

   El resto de esta sección es la referencia de la mayoría de las
procedimientos de utilidad proporcionados por ‘(guix build utils)’.

9.7.1 Tratamiento de nombres de archivo del almacén
---------------------------------------------------

Esta sección documenta procedimientos para el manejo de nombres de
archivo del almacén.

 -- Procedimiento Scheme: %store-directory
     Devuelve el nombre del directorio del almacén.

 -- Procedimiento Scheme: store-file-name? ARCHIVO
     Devuelve verdadero si ARCHIVO está en el almacén.

 -- Procedimiento Scheme: strip-store-file-name ARCHIVO
     Elimina ‘/gnu/store’ y el hash de ARCHIVO, un nombre de archivo del
     almacén.  El resultado es habitualmente una cadena
     ‘"PAQUETE-VERSIÓN"’.

 -- Procedimiento Scheme: package-name>name+version NOMBRE
     Cuando se proporciona NOMBRE, un nombre de paquete como
     ‘"foo-0.9.1b"’, devuelve dos valores: ‘"foo"’ y ‘"0.9.1b"’.  Cuando
     la perte de la versión no está disponible, se devuelve NOMBRE y
     ‘#f’.  Se considera que el primer guión seguido de un dígito
     introduce la parte de la versión.

9.7.2 Tipos de archivo
----------------------

Los siguientes procedimientos tratan con archivos y tipos de archivos.

 -- Procedimiento Scheme: directory-exists? DIR
     Devuelve ‘#t’ si DIR existe y es un directorio.

 -- Procedimiento Scheme: executable-file ARCHIVO
     Devuelve ‘#t’ si ARCHIVO existe y es ejecutable.

 -- Procedimiento Scheme: symbolic-link= ARCHIVO
     Devuelve ‘#t’ si ARCHIVO es enlace simbólico (“symlink”).

 -- Procedimiento Scheme: elf-file? ARCHIVO
 -- Procedimiento Scheme: ar-file? ARCHIVO
 -- Procedimiento Scheme: gzip-file? ARCHIVO
     Devuelve ‘#t’ si ARCHIVO es, respectivamente, un archivo ELF, un
     archivador ‘ar’ (como una biblioteca estática ‘.a’), o un archivo
     comprimido con gzip.

 -- Procedimiento Scheme: reset-gzip-timestamp ARCHIVO [#:keep-mtime?
          #t]
     Si ARCHIVO es un archivo gzip, reinicia su marca de tiempo embebida
     (como con ‘gzip --no-name’) y devuelve un valor verdadero.  En otro
     caso devuelve ‘#f’.  Cuando KEEP-MTIME? es verdadero, se preserva
     el tiempo de modificación del ARCHIVO.

9.7.3 Manipulación de archivos
------------------------------

Los siguientes procedimientos y macros sirven de ayuda en la creación,
modificación y borrado de archivos.  Proporcionan funcionalidades
comparables con las herrambientas comunes del intérprete de órdenes como
‘mkdir -p’, ‘cp -r’, ‘rm -r’ y ‘sed’.  Sirven de complemento a la
interfaz de sistema de archivos de Guile, la cual es extensa pero de
bajo nivel (*note (guile)POSIX::).

 -- Sintaxis Scheme: with-directory-excursion DIRECTORIO CUERPO...
     Ejecuta CUERPO con DIRECTORIO como el directorio actual del
     proceso.

     Esecialmente este macro cambia el directorio actual a DIRECTORIO
     antes de evaluar CUERPO, usando ‘chdir’ (*note (guile)Processes::).
     Se vuelve al directorio inicial en cuanto se abandone el ámbito
     dinámico de CUERPO, ya sea a través de su finalización normal o de
     una salida no-local como pueda ser una excepción.

 -- Procedimiento Scheme: mkdir-p DIR
     Crea el directorio DIR y todos sus predecesores.

 -- Procedimiento Scheme: install-file ARCHIVO DIRECTORIO
     Crea DIRECTORIO si no existe y copia ARCHIVO allí con el mismo
     nombre.

 -- Procedimiento Scheme: make-file-writable ARCHIVO
     Activa el permiso de escritura en ARCHIVO para su propietaria.

 -- Procedimiento Scheme: copy-recursively FUENTE DESTINO [#:log
          (current-output-port)] [#:follow-symlinks? #f]  [#:copy-file
     copy-file] [#:keep-mtime?  #f] [#:keep-permissions?  #t] Copy
     SOURCE directory to DESTINATION.  Follow symlinks if
     FOLLOW-SYMLINKS? is true; otherwise, just preserve them.  Call
     COPY-FILE to copy regular files.  When KEEP-MTIME? is true, keep
     the modification time of the files in SOURCE on those of
     DESTINATION.  When KEEP-PERMISSIONS? is true, preserve file
     permissions.  Write verbose output to the LOG port.

 -- Procedimiento Scheme: delete-file-recursively DIR [#:follow-mounts?
          #f]
     Borra DIR recursivamente, como ‘rm -rf’, sin seguir los enlaces
     simbólicos.  No atraviesa puntos de montaje tampoco, a no ser que
     FOLLOW-MOUNTS? sea verdadero.  Informa de los errores, pero no
     devuelve error por ellos.

 -- Sintaxis Scheme: substitute ARCHIVO ((EXPREG VAR-ENCONTRADA...)
          CUERPO...) ...

     Sustituye EXPREG en ARCHIVO con la cadena que devuelve CUERPO.  La
     evaluación de CUERPO se realiza con cada VAR-ENCONTRADA asociada
     con la subexpresión posicional correspondiente de la expresión
     regular.  Por ejemplo:

          (substitute* file
            (("hello")
             "good morning\n")
            (("foo([a-z]+)bar(.*)$" all letters end)
             (string-append "baz" letters end)))

     En este ejemplo, cada ver que una línea de ARCHIVO contiene ‘hola’,
     esto se sustituye por ‘buenos días’.  Cada vez que una línea del
     ARCHIVO corresponde con la segunda expresión regular, ‘todo’ se
     asocia con la cadena encontrada al completo, ‘letras’ toma el valor
     de la primera sub-expresión, y ‘fin’ se asocia con la última.

     Cuando una de las VAR-ENCONTRADA es ‘_’, no se asocia ninguna
     variable con la correspondiente subcadena.

     También puede proporcionarse una lista como ARCHIVO, en cuyo caso
     los nombres de archivo que contenga serán los que se sometan a las
     sustituciones.

     Tenga cuidado con el uso de ‘$’ para marcar el final de una línea;
     la cadena encontrada no contiene el caracter de salto de línea al
     final.

9.7.4 Búsqueda de archivos
--------------------------

Esta sección documenta procedimientos de búsqueda y filtrado de
archivos.

 -- Procedimiento Scheme: file-name-predicate EXPREG
     Devuelve un predicado que devuelve un valor verdadero cuando el
     nombre del archivo proporcionado sin la parte del directorio
     corresponde con EXPREG.

 -- Procedimiento Scheme: find-files DIR [PRED] [#:stat lstat]
          [#:directories? #f] [#:fail-on-error? #f]
     Devuelve una lista ordenada lexicográficamente de los archivos que
     se encuentran en DIR para los cuales PRED devuelve verdadero.  Se
     le proporcionan dos parámetros a PRED: la ruta absoluta del archivo
     y su búfer de stat; el predicado predeteminado siempre devuelve
     verdadero.  PRED también puede ser una expresión regular, en cuyo
     caso es equivalente a escribir ‘(file-name-predicate PRED)’.  STAT
     se usa para obtener información del archivo; el uso de ‘lstat’
     significa que no se siguen los enlaces simbólicos.  Si DIRECTORIES?
     es verdadero se incluyen también los directorios.  Si
     FAIL-ON-ERROR? es verdadero, se emite una excepción en caso de
     error.

   Aquí se pueden encontrar algunos ejemplos en los que se asume que el
directorio actual es la raíz del arbol de fuentes de Guix:

     ;; Enumera todos los archivos regulares en el directorio actual.
     (find-files ".")
     ⇒ ("./.dir-locals.el" "./.gitignore" ...)

     ;; Enumera todos los archivos .scm en gnu/services.
     (find-files "gnu/services" "\\.scm$")
     ⇒ ("gnu/services/admin.scm" "gnu/services/audio.scm" ...)

     ;; Enumera los archivos ar en el directorio actual.
     (find-files "." (lambda (file stat) (ar-file? file)))
     ⇒ ("./libformat.a" "./libstore.a" ...)

 -- Procedimiento Scheme: which PROGRAMA
     Devuelve el nombre de archivo completo para PROGRAMA tal y como se
     encuentra en ‘$PATH’, o ‘#f’ si no se ha encontrado PROGRAMA.

 -- Scheme Procedure: search-input-file INPUTS NAME
 -- Scheme Procedure: search-input-directory INPUTS NAME
     Return the complete file name for NAME as found in INPUTS;
     ‘search-input-file’ searches for a regular file and
     ‘search-input-directory’ searches for a directory.  If NAME could
     not be found, an exception is raised.

     Here, INPUTS must be an association list like ‘inputs’ and
     ‘native-inputs’ as available to build phases (*note Fases de
     construcción::).

   Here is a (simplified) example of how ‘search-input-file’ is used in
a build phase of the ‘wireguard-tools’ package:

     (add-after 'install 'wrap-wg-quick
       (lambda* (#:key inputs outputs #:allow-other-keys)
         (let ((coreutils (string-append (assoc-ref inputs "coreutils")
                                         "/bin")))
           (wrap-program (search-input-file outputs "bin/wg-quick")
             #:sh (search-input-file inputs "bin/bash")
             `("PATH" ":" prefix ,(list coreutils))))))

9.7.5 Program Invocation
------------------------

You’ll find handy procedures to spawn processes in this module,
essentially convenient wrappers around Guile’s ‘system*’ (*note
‘system*’: (guile)Processes.).

 -- Scheme Procedure: invoke PROGRAM ARGS...
     Invoke PROGRAM with the given ARGS.  Raise an ‘&invoke-error’
     exception if the exit code is non-zero; otherwise return ‘#t’.

     The advantage compared to ‘system*’ is that you do not need to
     check the return value.  This reduces boilerplate in
     shell-script-like snippets for instance in package build phases.

 -- Scheme Procedure: invoke-error? C
     Return true if C is an ‘&invoke-error’ condition.

 -- Scheme Procedure: invoke-error-program C
 -- Scheme Procedure: invoke-error-arguments C
 -- Scheme Procedure: invoke-error-exit-status C
 -- Scheme Procedure: invoke-error-term-signal C
 -- Scheme Procedure: invoke-error-stop-signal C
     Access specific fields of C, an ‘&invoke-error’ condition.

 -- Scheme Procedure: report-invoke-error C [PORT]
     Report to PORT (by default the current error port) about C, an
     ‘&invoke-error’ condition, in a human-friendly way.

     Typical usage would look like this:

          (use-modules (srfi srfi-34) ;for 'guard'
                       (guix build utils))

          (guard (c ((invoke-error? c)
                     (report-invoke-error c)))
            (invoke "date" "--imaginary-option"))

          ⊣ command "date" "--imaginary-option" failed with status 1

 -- Scheme Procedure: invoke/quiet PROGRAM ARGS...
     Invoke PROGRAM with ARGS and capture PROGRAM’s standard output and
     standard error.  If PROGRAM succeeds, print nothing and return the
     unspecified value; otherwise, raise a ‘&message’ error condition
     that includes the status code and the output of PROGRAM.

     Here’s an example:

          (use-modules (srfi srfi-34) ;for 'guard'
                       (srfi srfi-35) ;for 'message-condition?'
                       (guix build utils))

          (guard (c ((message-condition? c)
                     (display (condition-message c))))
            (invoke/quiet "date")  ;all is fine
            (invoke/quiet "date" "--imaginary-option"))

          ⊣ 'date --imaginary-option' exited with status 1; output follows:

              date: unrecognized option '--imaginary-option'
              Try 'date --help' for more information.

9.7.6 Fases de construcción
---------------------------

‘(guix build utils)’ también contiene herramientas para la manipulación
de las fases de construcción usadas por los sistemas de construcción
(*note Sistemas de construcción::).  Las fases de construcción se
representan como listas asociativas o “alists” (*note (guile)Association
Lists::) donde cada clave es un símbolo que nombra a la fase, y el valor
asociado es un procedimiento (*note Fases de construcción::).

   Tanto el propio Guile como el módulo ‘(srfi srfi-1)’ proporcionan
herramientas para la manipulación de listas asociativas.  El módulo
‘(guix build utils)’ complementa estas con herramientas pensadas para
las fases de construcción.

 -- Sintaxis Scheme: modify-phases FASES CLÁUSULA...
     Modifica FASES de manera secuencial com cada indique cada CLÁUSULA,
     que puede tener una de las siguentes formas:

          (delete NOMBRE-FASE)
          (replace NOMBRE-FASE NUEVA-FASE)
          (add-before NOMBRE-FASE NOMBRE-NUEVA-FASE NUEVA-FASE)
          (add-after NOMBRE-FASE NOMBRE-NUEVA-FASE NUEVA-FASE)

     Donde cada NOMBRE-FASE y NOMBRE-NUEVA-FASE es una expresión que
     evalúa aun símbolo, y NUEVA-FASE es una expresión que evalúa a un
     procedimiento.

   El siguiente ejemplo se ha tomado de la definición del paquete
‘grep’.  Añade una fase que se ejecuta tras la fase ‘install’, llamada
‘fix-egrep-and-fgrep’.  Dicha fase es un procedimiento (‘lambda*’ genera
procedimientos anónimos) que toma un parámetro de palabra clave
‘#:outputs’ e ignora el resto (*note (guile)Optional Arguments:: para
obtener más información sobre ‘lambda*’ y los parámetros opcionales y de
palabras clave).  La fase usa ‘substitute*’ para modificar los guiones
‘egrep’ y ‘fgrep’ instalados para que hagan referencia a ‘grep’ con su
ruta de archivo absoluta:

     (modify-phases %standard-phases
       (add-after 'install 'fix-egrep-and-fgrep
         ;; Patch 'egrep' and 'fgrep' to execute 'grep' via its
         ;; absolute file name instead of searching for it in $PATH.
         (lambda* (#:key outputs #:allow-other-keys)
           (let* ((out (assoc-ref outputs "out"))
                  (bin (string-append out "/bin")))
             (substitute* (list (string-append bin "/egrep")
                                (string-append bin "/fgrep"))
               (("^exec grep")
                (string-append "exec " bin "/grep")))))))

   En el siguiente ejemplo se modifican las fases de dos maneras: se
elimina la fase estándar ‘configure’, posiblemente porque el paquete no
tiene un guión ‘configure’ ni nada similar, y la fase ‘install’
predeterminada se sustituye por una que copia manualmente el archivo
ejecutable que se debe instalar:

     (modify-phases %standard-phases
       (delete 'configure)      ;no 'configure' script
       (replace 'install
         (lambda* (#:key outputs #:allow-other-keys)
           ;; The package's Makefile doesn't provide an "install"
           ;; rule so do it by ourselves.
           (let ((bin (string-append (assoc-ref outputs "out")
                                     "/bin")))
             (install-file "footswitch" bin)
             (install-file "scythe" bin)))))

9.7.7 Wrappers
--------------

It is not unusual for a command to require certain environment variables
to be set for proper functioning, typically search paths (*note Search
Paths::).  Failing to do that, the command might fail to find files or
other commands it relies on, or it might pick the “wrong” ones—depending
on the environment in which it runs.  Examples include:

   • a shell script that assumes all the commands it uses are in ‘PATH’;

   • a Guile program that assumes all its modules are in
     ‘GUILE_LOAD_PATH’ and ‘GUILE_LOAD_COMPILED_PATH’;

   • a Qt application that expects to find certain plugins in
     ‘QT_PLUGIN_PATH’.

   For a package writer, the goal is to make sure commands always work
the same rather than depend on some external settings.  One way to
achieve that is to “wrap” commands in a thin script that sets those
environment variables, thereby ensuring that those run-time dependencies
are always found.  The wrapper would be used to set ‘PATH’,
‘GUILE_LOAD_PATH’, or ‘QT_PLUGIN_PATH’ in the examples above.

   To ease that task, the ‘(guix build utils)’ module provides a couple
of helpers to wrap commands.

 -- Scheme Procedure: wrap-program PROGRAM [#:sh SH] [#:rest VARIABLES]
          Make a wrapper for PROGRAM.
     VARIABLES should look like this:

          '(VARIABLE DELIMITER POSITION LIST-OF-DIRECTORIES)

     where DELIMITER is optional.  ‘:’ will be used if DELIMITER is not
     given.

     For example, this call:

          (wrap-program "foo"
                        '("PATH" ":" = ("/gnu/.../bar/bin"))
                        '("CERT_PATH" suffix ("/gnu/.../baz/certs"
                                              "/qux/certs")))

     will copy ‘foo’ to ‘.foo-real’ and create the file ‘foo’ with the
     following contents:

          #!location/of/bin/bash
          export PATH="/gnu/.../bar/bin"
          export CERT_PATH="$CERT_PATH${CERT_PATH:+:}/gnu/.../baz/certs:/qux/certs"
          exec -a $0 location/of/.foo-real "$@"

     If PROGRAM has previously been wrapped by ‘wrap-program’, the
     wrapper is extended with definitions for VARIABLES.  If it is not,
     SH will be used as the interpreter.

 -- Scheme Procedure: wrap-script PROGRAM [#:guile GUILE] [#:rest
          VARIABLES] Wrap the script PROGRAM
     such that VARIABLES are set first.  The format of VARIABLES is the
     same as in the ‘wrap-program’ procedure.  This procedure differs
     from ‘wrap-program’ in that it does not create a separate shell
     script.  Instead, PROGRAM is modified directly by prepending a
     Guile script, which is interpreted as a comment in the script’s
     language.

     Special encoding comments as supported by Python are recreated on
     the second line.

     Note that this procedure can only be used once per file as Guile
     scripts are not supported.


File: guix.es.info,  Node: Search Paths,  Next: El almacén,  Prev: Utilidades de construcción,  Up: Interfaz programática

9.8 Search Paths
================

Many programs and libraries look for input data in a “search path”, a
list of directories: shells like Bash look for executables in the
command search path, a C compiler looks for ‘.h’ files in its header
search path, the Python interpreter looks for ‘.py’ files in its search
path, the spell checker has a search path for dictionaries, and so on.

   Search paths can usually be defined or overridden via environment
variables (*note (libc)Environment Variables::).  For example, the
search paths mentioned above can be changed by defining the ‘PATH’,
‘C_INCLUDE_PATH’, ‘PYTHONPATH’ (or ‘GUIX_PYTHONPATH’), and ‘DICPATH’
environment variables—you know, all these something-PATH variables that
you need to get right or things “won’t be found”.

   You may have noticed from the command line that Guix “knows” which
search path environment variables should be defined, and how.  When you
install packages in your default profile, the file
‘~/.guix-profile/etc/profile’ is created, which you can “source” from
the shell to set those variables.  Likewise, if you ask ‘guix shell’ to
create an environment containing Python and NumPy, a Python library, and
if you pass it the ‘--search-paths’ option, it will tell you about
‘PATH’ and ‘GUIX_PYTHONPATH’ (*note Invoking guix shell::):

     $ guix shell python python-numpy --pure --search-paths
     export PATH="/gnu/store/...-profile/bin"
     export GUIX_PYTHONPATH="/gnu/store/...-profile/lib/python3.9/site-packages"

   When you omit ‘--search-paths’, it defines these environment
variables right away, such that Python can readily find NumPy:

     $ guix shell python python-numpy -- python3
     Python 3.9.6 (default, Jan  1 1970, 00:00:01)
     [GCC 10.3.0] on linux
     Type "help", "copyright", "credits" or "license" for more information.
     >>> import numpy
     >>> numpy.version.version
     '1.20.3'

   For this to work, the definition of the ‘python’ package _declares_
the search path it cares about and its associated environment variable,
‘GUIX_PYTHONPATH’.  It looks like this:

     (package
       (name "python")
       (version "3.9.9")
       ;; some fields omitted...
       (native-search-paths
        (list (search-path-specification
               (variable "GUIX_PYTHONPATH")
               (files (list "lib/python/3.9/site-packages"))))))

   What this ‘native-search-paths’ field says is that, when the ‘python’
package is used, the ‘GUIX_PYTHONPATH’ environment variable must be
defined to include all the ‘lib/python/3.9/site-packages’
sub-directories encountered in its environment.  (The ‘native-’ bit
means that, if we are in a cross-compilation environment, only native
inputs may be added to the search path; *note ‘search-paths’: Referencia
de package.)  In the NumPy example above, the profile where ‘python’
appears contains exactly one such sub-directory, and ‘GUIX_PYTHONPATH’
is set to that.  When there are several
‘lib/python/3.9/site-packages’—this is the case in package build
environments—they are all added to ‘GUIX_PYTHONPATH’, separated by
colons (‘:’).

     Nota: Notice that ‘GUIX_PYTHONPATH’ is specified as part of the
     definition of the ‘python’ package, and _not_ as part of that of
     ‘python-numpy’.  This is because this environment variable
     “belongs” to Python, not NumPy: Python actually reads the value of
     that variable and honors it.

     Corollary: if you create a profile that does not contain ‘python’,
     ‘GUIX_PYTHONPATH’ will _not_ be defined, even if it contains
     packages that provide ‘.py’ files:

          $ guix shell python-numpy --search-paths --pure
          export PATH="/gnu/store/...-profile/bin"

     This makes a lot of sense if we look at this profile in isolation:
     no software in this profile would read ‘GUIX_PYTHONPATH’.

   Of course, there are many variations on that theme: some packages
honor more than one search path, some use separators other than colon,
some accumulate several directories in their search path, and so on.  A
more complex example is the search path of libxml2: the value of the
‘XML_CATALOG_FILES’ environment variable is space-separated, it must
contain a list of ‘catalog.xml’ files (not directories), which are to be
found in ‘xml’ sub-directories—nothing less.  The search path
specification looks like this:

     (package
       (name "libxml2")
       ;; some fields omitted
       (native-search-paths
        (list (search-path-specification
               (variable "XML_CATALOG_FILES")
               (separator " ")
               (files '("xml"))
               (file-pattern "^catalog\\.xml$")
               (file-type 'regular)))))

   Worry not, search path specifications are usually not this tricky.

   The ‘(guix search-paths)’ module defines the data type of search path
specifications and a number of helper procedures.  Below is the
reference of search path specifications.

 -- Data Type: search-path-specification
     The data type for search path specifications.

     ‘variable’
          The name of the environment variable for this search path (a
          string).

     ‘files’
          The list of sub-directories (strings) that should be added to
          the search path.

     ‘separator’ (default: ‘":"’)
          The string used to separate search path components.

          As a special case, a ‘separator’ value of ‘#f’ specifies a
          “single-component search path”—in other words, a search path
          that cannot contain more than one element.  This is useful in
          some cases, such as the ‘SSL_CERT_DIR’ variable (honored by
          OpenSSL, cURL, and a few other packages) or the
          ‘ASPELL_DICT_DIR’ variable (honored by the GNU Aspell spell
          checker), both of which must point to a single directory.

     ‘file-type’ (default: ‘'directory’)
          The type of file being matched—‘'directory’ or ‘'regular’,
          though it can be any symbol returned by ‘stat:type’ (*note
          ‘stat’: (guile)File System.).

          In the libxml2 example above, we would match regular files; in
          the Python example, we would match directories.

     ‘file-pattern’ (default: ‘#f’)
          This must be either ‘#f’ or a regular expression specifying
          files to be matched _within_ the sub-directories specified by
          the ‘files’ field.

          Again, the libxml2 example shows a situation where this is
          needed.

   Some search paths are not tied by a single package but to many
packages.  To reduce duplications, some of them are pre-defined in
‘(guix search-paths)’.

 -- Scheme Variable: $SSL_CERT_DIR
 -- Scheme Variable: $SSL_CERT_FILE
     These two search paths indicate where X.509 certificates can be
     found (*note Certificados X.509::).

   These pre-defined search paths can be used as in the following
example:

     (package
       (name "curl")
       ;; some fields omitted ...
       (native-search-paths (list $SSL_CERT_DIR $SSL_CERT_FILE)))

   How do you turn search path specifications on one hand and a bunch of
directories on the other hand in a set of environment variable
definitions?  That’s the job of ‘evaluate-search-paths’.

 -- Scheme Procedure: evaluate-search-paths SEARCH-PATHS DIRECTORIES
          [GETENV] Evaluate SEARCH-PATHS, a list of
     search-path specifications, for DIRECTORIES, a list of directory
     names, and return a list of specification/value pairs.  Use GETENV
     to determine the current settings and report only settings not
     already effective.

   The ‘(guix profiles)’ provides a higher-level helper procedure,
‘load-profile’, that sets the environment variables of a profile.


File: guix.es.info,  Node: El almacén,  Next: Derivaciones,  Prev: Search Paths,  Up: Interfaz programática

9.9 El almacén
==============

Conceptualmente, el “almacén” es el lugar donde se almacenan las
derivaciones cuya construcción fue satisfactoria—por defecto,
‘/gnu/store’.  Los subdirectorios en el almacén se denominan “elementos
del almacén” o “rutas del almacén” en ocasiones.  El almacén tiene una
base de datos asociada que contiene información como las rutas del
almacén a las que referencia cada ruta del almacén, y la lista de
elementos _válidos_ del almacén—los resultados de las construcciones
satisfactorias.  Esta base de datos reside en ‘LOCALSTATEDIR/guix/db’,
donde LOCALSTATEDIR es el directorio de estado especificado vía
‘--localstatedir’ en tiempo de configuración, normalmente ‘/var’.

   El almacén _siempre_ es accedido a través del daemon en delegación de
sus clientes (*note Invocación de guix-daemon::).  Para manipular el
almacén, los clientes se conectan al daemon por un socket de dominio
Unix, le envían peticiones y leen el resultado—esto son llamadas a
procedimientos remotos, o RPC.

     Nota: Las usuarias _nunca_ deben modificar archivos directamente
     bajo el directorio ‘/gnu/store’.  Esto llevaría a inconsistencias y
     rompería las premisas de inmutabilidad del modelo funcional de Guix
     (*note Introducción::).

     *Note ‘guix gc --verify’: Invocación de guix gc, para información
     sobre cómo comprobar la integridad del almacén e intentar
     recuperarse de modificaciones accidentales.

   El módulo ‘(guix store)’ proporciona procedimientos para conectarse
al daemon y realizar RPCs.  Estos se describen más adelante.  Por
defecto, ‘open-connection’, y por tanto todas las órdenes ‘guix’, se
conectan al daemon local o a la URI especificada en la variable de
entorno ‘GUIX_DAEMON_SOCKET’.

 -- Variable de entorno: GUIX_DAEMON_SOCKET
     Cuando se ha definido, el valor de esta variable debe ser un nombre
     de archivo o una URI designando el punto de conexión del daemon.
     Cuando es un nombre de archivo, denota un socket de dominio Unix al
     que conectarse.  Además de nombres de archivos, los esquemas de URI
     aceptados son:

     ‘file’
     ‘unix’
          Estos son equivalentes a los sockets de dominio Unix.
          ‘file:///var/guix/daemon-socket/socket’ es equivalente a
          ‘/var/guix/daemon-socket/socket’.

     ‘guix’
          Estas URI denotan conexiones sobre TCP/IP, sin cifrado ni
          verificación de la máquina remota.  La URI debe especificar el
          nombre de máquina y opcionalmente un número de puerto (por
          defecto se usa el puerto 44146):

               guix://principal.guix.example.org:1234

          Esta configuración es apropiada para redes locales, como
          clusters, donde únicamente los nodos de confianza pueden
          conectarse al daemon de construcción en
          ‘principal.guix.example.org’.

          La opción ‘--listen’ de ‘guix-daemon’ puede usarse para
          indicarle que escuche conexiones TCP (*note ‘--listen’:
          Invocación de guix-daemon.).

     ‘ssh’
          These URIs allow you to connect to a remote daemon over SSH.
          This feature requires Guile-SSH (*note Requisitos::) and a
          working ‘guile’ binary in ‘PATH’ on the destination machine.
          It supports public key and GSSAPI authentication.  A typical
          URL might look like this:

               ssh://carlos@guix.example.org:22

          Como con ‘guix copy’, se tienen en cuenta los archivos
          habituales de configuración del cliente OpenSSH (*note
          Invocación de guix copy::).

     Esquemas URI adicionales pueden ser aceptados en el futuro.

          Nota: La conexión con daemon de construcción remotos se
          considera experimental en 1.4.0rc2.  Por favor, contacte con
          nosotras para compartir cualquier problema o sugerencias que
          pueda tener (*note Contribuir::).

 -- Procedimiento Scheme: open-connection [URI] [#:reserve-space? #t]
     Abre una conexión al daemon a través del socket de dominio Unix
     apuntado por URI (una cadena).  Cuando RESERVE-SPACE? es verdadero,
     le indica que reserve un poco de espacio extra en el sistema de
     archivos de modo que el recolector de basura pueda operar incluso
     cuando el disco se llene.  Devuelve un objeto servidor.

     El valor por defecto de URI es ‘%default-socket-path’, que ese la
     ruta esperada según las opciones proporcionadas a ‘configure’.

 -- Procedimiento Scheme: close-connection SERVIDOR
     Cierra la conexión al SERVIDOR.

 -- Variable Scheme: current-build-output-port
     Esta variable está enlazada a un parámetro SRFI-39, que referencia
     al puerto donde los logs de construcción y error enviados por el
     daemon deben escribirse.

   Los procedimientos que realizan RPCs toman todos como primer
parámetro un objeto servidor.

 -- Procedimiento Scheme: valid-path? SERVIDOR RUTA
     Devuelve ‘#t’ cuando RUTA designa un elemento válido del almacén y
     ‘#f’ en otro caso (un elemento no-válido puede existir en el disco
     pero aun así no ser válido, por ejemplo debido a que es el
     resultado de una construcción que se interrumpió o falló).

     Una condición ‘&store-protocol-error’ se eleva si RUTA no contiene
     como prefijo el directorio del almacén (‘/gnu/store’).

 -- Procedimiento Scheme: add-text-to-store SERVIDOR NOMBRE TEXTO
          [REFERENCIAS]
     Añade TEXTO bajo el archivo NOMBRE en el almacén, y devuelve su
     ruta en el almacén.  REFERENCIAS es la lista de rutas del almacén a
     las que hace referencia la ruta del almacén resultante.

 -- Procedimiento Scheme: build-derivations ALMACÉN DERIVACIONES [MODO]
     Construye DERIVACIONES, una lista de objetos ‘<derivation>’,
     nombres de archivo ‘.drv’, o pares derivación/salida, usando el
     MODO especificado—‘(build-mode normal)’ en caso de omisión.

   Fíjese que el módulo ‘(guix monads)’ proporciona una mónada así como
versiones monádicas de los procedimientos previos, con el objetivo de
hacer más conveniente el trabajo con código que accede al almacén (*note
La mónada del almacén::).

   Esta sección actualmente está incompleta.


File: guix.es.info,  Node: Derivaciones,  Next: La mónada del almacén,  Prev: El almacén,  Up: Interfaz programática

9.10 Derivaciones
=================

Las acciones de construcción a bajo nivel y el entorno en el que se
realizan se representan mediante “derivaciones”.  Una derivación
contiene las siguientes piezas de información:

   • Las salidas de la derivación—las derivaciones producen al menos un
     archivo o directorio en el almacén, pero pueden producir más.

   • Las entradas de las derivaciones—es decir, sus dependencias de
     tiempo de construcción—, que pueden ser otras derivaciones o
     simples archivos en el almacén (parches, guiones de construcción,
     etc.).

   • El tipo de sistema objetivo de la derivación—por ejemplo,
     ‘x86_64-linux’.

   • El nombre de archivo del guión de construcción en el almacén, junto
     a los parámetros que se le deben pasar.

   • Una lista de variables de entorno a ser definidas.

   Las derivaciones permiten a los clientes del daemon comunicar
acciones de construcción al almacén.  Existen en dos formas: como una
representación en memoria, tanto en el lado del cliente como el del
daemon, y como archivos en el almacén cuyo nombre termina en
‘.drv’—estos archivos se conocen como “rutas de derivación”.  Las rutas
de derivación se pueden proporcionar al procedimiento
‘build-derivations’ para que realice las acciones de construcción
prescritas (*note El almacén::).

   Operaciones como la descarga de archivos y las instantáneas de un
control de versiones para las cuales el hash del contenido esperado se
conoce previamente se modelan como “derivaciones de salida fija”.  Al
contrario que las derivaciones normales, las salidas de una derivación
de salida fija son independientes de sus entradas—por ejemplo, la
descarga del código fuente produce el mismo resultado independientemente
del método de descarga y las herramientas usadas.

   Las derivaciones de salida—es decir, los resultados de
construcción—tienen un conjunto de “referencias”, del que informa la RPC
‘references’ o la orden ‘guix gc --references’ (*note Invocación de guix
gc::).  Las referencias son el conjunto de dependencias en tiempo de
ejecución de los resultados de construcción.  Las referencias son un
subconjunto de las entradas de la derivación; el daemon de construcción
calcula este subconjunto de forma automática mediante el procesado de
todos los archivos en las salidas.

   El módulo ‘(guix derivations)’ proporciona una representación de
derivaciones como objetos Scheme, junto a procedimientos para crear y
manipular de otras formas derivaciones.  La primitiva de más bajo nivel
para crear una derivación es el procedimiento ‘derivation’:

 -- Procedimiento Scheme: derivation ALMACÉN NOMBRE CONSTRUCTOR ARGS
          [#:outputs '("out")] [#:hash #f] [#:hash-algo #f]
          [#:recursive? #f] [#:inputs '()] [#:env-vars '()] [#:system
          (%current-system)] [#:references-graphs #f]
          [#:allowed-references #f] [#:disallowed-references #f]
          [#:leaked-env-vars #f] [#:local-build? #f] [#:substitutable?
          #t] [#:properties '()]
     Construye una derivación con los parámetros proporcionados, y
     devuelve el objeto ‘<derivation>’ resultante.

     Cuando se proporcionan HASH y HASH-ALGO, una “derivación de salida
     fija” se crea—es decir, una cuyo resultado se conoce de antemano,
     como la descarga de un archivo.  Si, además, RECURSIVE? es
     verdadero, entonces la salida fijada puede ser un archivo
     ejecutable o un directorio y HASH debe ser el hash de un archivador
     que contenga esta salida.

     Cuando REFERENCES-GRAPHS es verdadero, debe ser una lista de pares
     de nombre de archivo/ruta del almacén.  En ese caso, el grafo de
     referencias de cada ruta del almacén se exporta en el entorno de
     construcción del archivo correspondiente, en un formato de texto
     simple.

     Cuando ALLOWED-REFERENCES es verdadero, debe ser una lista de
     elementos del almacén o salidas a las que puede hacer referencia la
     salida de la derivación.  Del mismo modo, DISALLOWED-REFERENCES, en
     caso de ser verdadero, debe ser una lista de cosas a las que las
     salidas _no_ pueden hacer referencia.

     Cuando LEAKED-ENV-VARS es verdadero, debe ser una lista de cadenas
     que denoten variables de entorno que se permite “escapar” del
     entorno del daemon al entorno de construcción.  Esto es únicamente
     aplicable a derivaciones de salida fija—es decir, cuando HASH es
     verdadero.  El uso principal es permitir que variables como
     ‘http_proxy’ sean pasadas a las derivaciones que descargan
     archivos.

     Cuando LOCAL-BUILD? es verdadero, declara que la derivación no es
     una buena candidata para delegación y debe ser construida
     localmente (*note Configuración de delegación del daemon::).  Este
     es el caso para pequeñas derivaciones donde los costes de
     transferencia de datos sobrepasarían los beneficios.

     Cuando SUBSTITUTABLE? es falso, declara que las sustituciones de la
     salida de la derivación no deben usarse (*note Sustituciones::).
     Esto es útil, por ejemplo, cuando se construyen paquetes que
     capturan detalles sobre el conjunto de instrucciones de la CPU
     anfitriona.

     PROPERTIES debe ser una lista asociada que describe “propiedades”
     de la derivación.  Debe mantenerse tal cual, sin interpretar, en la
     derivación.

Esto es un ejemplo con un guión de shell como constructor, asumiendo que
ALMACÉN es una conexión abierta al daemon, BASH apunta al ejecutable
Bash en el almacén:

     (use-modules (guix utils)
                  (guix store)
                  (guix derivations))

     (let ((constructor   ; añade el guión de Bash al almacén
             (add-text-to-store store "mi-constructor.sh"
                                "echo hola mundo > $out\n" '())))
       (derivation almacen "foo"
                   bash `("-e" ,builder)
                   #:inputs `((,bash) (,constructor))
                   #:env-vars '(("HOME" . "/sindirectorio"))))
     ⇒ #<derivation /gnu/store/...-foo.drv => /gnu/store/...-foo>

   Como puede suponerse, el uso directo de esta primitiva es algo
enrevesado.  Una mejor aproximación es escribir guiones de construcción
en Scheme, ¡por supuesto!  La mejor forma de hacerlo es escribir el
código de construcción como una “expresión-G”, y pasarla a
‘gexp->derivation’.  Para más información, *note Expresiones-G::.

   En otros tiempos, ‘gexp->derivation’ no existía y la creación de
derivaciones con código de construcción escrito en Scheme se conseguía
con ‘build-expression->derivation’, documentada más adelante.  Este
procedimiento está ahora obsoleto en favor del procedimiento
‘gexp->derivation’ mucho más conveniente.

 -- Procedimiento Scheme: build-expression->derivation ALMACÉN NOMBRE
          EXP [#:system (%current-system)] [#:inputs '()] [#:outputs
          '("out")] [#:hash #f] [#:hash-algo #f] [#:recursive? #f]
          [#:env-vars '()] [#:modules '()] [#:references-graphs #f]
          [#:allowed-references #f] [#:disallowed-references #f]
          [#:local-build? #f] [#:substitutable? #t] [#:guile-for-build
          #f]
     Devuelve una derivación que ejecuta la expresión Scheme EXP como un
     constructor para la derivación NOMBRE.  INPUTS debe ser una lista
     de tuplas ‘(nombre ruta-drv sub-drv)’; cuando SUB-DRV se omite, se
     asume ‘"out"’.  MODULES es una lista de nombres de módulos Guile de
     la ruta actual de búsqueda a copiar en el almacén, compilados, y
     poner a disposición en la ruta de carga durante la ejecución de
     EXP—por ejemplo, ‘((guix build utils) (guix build
     gnu-build-system))’.

     EXP se evalúa en un entorno donde ‘%outputs’ está asociada a una
     lista de pares salida/ruta, y donde ‘%build-inputs’ está asociada a
     una lista de pares cadena/ruta-de-salida que provienen de INPUTS.
     De manera opcional, ENV-VARS es una lista de pares de cadenas que
     especifican el nombre y el valor de las variables de entorno
     visibles al constructor.  El constructor termina pasando el
     resultado de EXP a ‘exit’; por tanto, cuando EXP devuelve ‘#f’, la
     construcción se considera fallida.

     EXP se construye usando GUILE-FOR-BUILD (una derivación).  Cuando
     GUILE-FOR-BUILD se omite o es ‘#f’, el valor del fluido
     ‘%guile-for-build’ se usa en su lugar.

     Véase el procedimiento ‘derivation’ para el significado de
     REFERENCES-GRAPHS, ALLOWED-REFERENCES, DISALLOWED-REFERENCES,
     LOCAL-BUILD? y SUBSTITUTABLE?.

Aquí está un ejemplo de derivación de salida única que crea un
directorio que contiene un archivo:

     (let ((constructor '(let ((salida (assoc-ref %outputs "out")))
                           (mkdir salida)    ; crea /gnu/store/...-goo
                           (call-with-output-file (string-append salida "/prueba")
                             (lambda (p)
                               (display '(hola guix) p))))))
       (build-expression->derivation almacen "goo" constructor))

     ⇒ #<derivation /gnu/store/...-goo.drv => ...>


File: guix.es.info,  Node: La mónada del almacén,  Next: Expresiones-G,  Prev: Derivaciones,  Up: Interfaz programática

9.11 La mónada del almacén
==========================

Los procedimientos que operan en el almacén descritos en la sección
previa toman todos una conexión abierta al daemon de construcción en su
primer parámetro.  Aunque el modelo subyacente es funcional, tienen o
bien efectos secundarios o dependen del estado actual del almacén.

   Lo anterior es inconveniente: la conexión al daemon de construcción
tiene que proporcionarse en todas estas funciones, haciendo imposible la
composición de funciones que no toman ese parámetro con funciones que sí
lo hacen.  Lo último puede ser problemático: ya que las operaciones del
almacén tienen efectos secundarios y/o dependen del estado externo,
deben ser secuenciadas de manera adecuada.

   Aquí es donde entra en juego el módulo ‘(guix monads)’.  Este módulo
proporciona un entorno para trabajar con “mónadas”, y una mónada
particularmente útil para nuestros usos, la “mónada del almacén”.  Las
mónadas son una construcción que permite dos cosas: asociar “contexto”
con valores (en nuestro caso, el contexto es el almacén), y la
construcción de secuencias de computaciones (aquí computaciones incluye
accesos al almacén).  Los valores en una mónada—valores que transportan
este contexto adicional—se llaman “valores monádicos”; los
procedimientos que devuelven dichos valores se llaman “procedimientos
monádicos”.

   Considere este procedimiento “normal”:

     (define (enlace-sh almacen)
       ;; Devuelve una derivación que enlaza el ejecutable 'bash'.
       (let* ((drv (package-derivation store bash))
              (out (derivation->output-path drv))
              (sh  (string-append out "/bin/bash")))
         (build-expression->derivation store "sh"
                                       `(symlink ,sh %output))))

   Mediante el uso de ‘(guix monads)’ y ‘(guix gexp)’, puede
reescribirse como una función monádica:

     (define (enlace-sh)
       ;; Lo mismo, pero devuelve un valor monádico.
       (mlet %store-monad ((drv (package->derivation bash)))
         (gexp->derivation "sh"
                           #~(symlink (string-append #$drv "/bin/bash")
                                      #$output))))

   Hay varias cosas a tener en cuenta en la segunda versión: el
parámetro ‘store’ ahora es implícito y es “hilado en las llamadas a los
procedimientos monádicos ‘package->derivation’ y ‘gexp->derivation’, y
el valor monádico devuelto por ‘package->derivation’ es “asociado”
mediante el uso de ‘mlet’ en vez de un simple ‘let’.

   Al final, la llamada a ‘package->derivation’ puede omitirse ya que
tendrá lugar implícitamente, como veremos más adelante (*note
Expresiones-G::):

     (define (enlace-sh)
       (gexp->derivation "sh"
                         #~(symlink (string-append #$bash "/bin/bash")
                                    #$output)))

   La ejecución del procedimiento monádico ‘enlace-para-sh’ no tiene
ningún efecto.  Como alguien dijo una vez, “sales de una mónada como
sales de un edificio en llamas: corriendo” (run en inglés).  Por tanto,
para salir de la mónada y obtener el efecto deseado se debe usar
‘run-with-store’:

     (run-with-store (open-connection) (enlace-sh))
     ⇒ /gnu/store/...-enlace-para-sh

   Note that the ‘(guix monad-repl)’ module extends the Guile REPL with
new “commands” to make it easier to deal with monadic procedures:
‘run-in-store’, and ‘enter-store-monad’ (*note Using Guix
Interactively::).  The former is used to “run” a single monadic value
through the store:

     scheme@(guile-user)> ,run-in-store (package->derivation hello)
     $1 = #<derivation /gnu/store/...-hello-2.9.drv => ...>

   El último entra en un entorno interactivo recursivo, donde todos los
valores devueltos se ejecutan automáticamente a través del almacén:

     scheme@(guile-user)> ,enter-store-monad
     store-monad@(guile-user) [1]> (package->derivation hello)
     $2 = #<derivation /gnu/store/...-hello-2.9.drv => ...>
     store-monad@(guile-user) [1]> (text-file "foo" "Hello!")
     $3 = "/gnu/store/...-foo"
     store-monad@(guile-user) [1]> ,q
     scheme@(guile-user)>

Fíjese que los valores no-monádicos no pueden devolverse en el entorno
interactivo ‘store-monad’.

   Other meta-commands are available at the REPL, such as ‘,build’ to
build a file-like object (*note Using Guix Interactively::).

   Las formas sintácticas principales para tratar con mónadas en general
se proporcionan por el módulo ‘(guix monads)’ y se describen a
continuación.

 -- Sintaxis Scheme: with-monad MÓNADA CUERPO ...
     Evalúa cualquier forma ‘>>=’ o ‘return’ en CUERPO como estando en
     MÓNADA.

 -- Sintaxis Scheme: return VAL
     Devuelve el valor monádico que encapsula VAL.

 -- Sintaxis Scheme: >>= MVAL MPROC ...
     “Asocia” el valor monádico MVAL, pasando su “contenido” a los
     procedimientos monádicos MPROC...(1).  Puede haber un MPROC o
     varios, como en este ejemplo:

          (run-with-state
              (with-monad %state-monad
                (>>= (return 1)
                     (lambda (x) (return (+ 1 x)))
                     (lambda (x) (return (* 2 x)))))
            'un-estado)

          ⇒ 4
          ⇒ un-estado

 -- Sintaxis Scheme: mlet MÓNADA ((VAR MVAL) ...) CUERPO ...
 -- Sintaxis Scheme: mlet* MÓNADA ((VAR MVAL) ...) CUERPO ... Asocia las
          variables VAR a los valores monádicos
     MVAL en CUERPO, el cual es una secuencia de expresiones.  Como con
     el operador bind, esto puede pensarse como el “desempaquetado” del
     valor crudo no-monádico dentro del ámbito del CUERPO.  La forma
     (VAR -> VAL) asocia VAR al valor “normal” VAL, como en ‘let’.  Las
     operaciones de asociación ocurren en secuencia de izquierda a
     derecha.  La última expresión de CUERPO debe ser una expresión
     monádica, y su resultado se convertirá en el resultado de ‘mlet’ o
     ‘mlet*’ cuando se ejecute en la MÓNADA.

     ‘mlet*’ es a ‘mlet’ lo que ‘let*’ es a ‘let’ (*note (guile)Local
     Bindings::).

 -- Sistema Scheme: mbegin MÓNADA MEXP ...
     Asocia MEXP y las siguientes expresiones monádicas en secuencia,
     devolviendo el resultado de la última expresión.  Cada expresión en
     la secuencia debe ser una expresión monádica.

     Esto es similar a ‘mlet’, excepto que los valores devueltos por las
     expresiones monádicas se ignoran.  En ese sentido el funcionamiento
     es análogo a ‘begin’ pero aplicado a expresiones monádicas.

 -- Sistema Scheme: mwhen CONDICIÓN MEXP0 MEXP* ...
     Cuando CONDICIÓN es verdadero, evalúa la secuencia de expresiones
     monádicas MEXP0..MEXP* como dentro de ‘mbegin’.  Cuando CONDICIÓN
     es falso, devuelve ‘*unespecified*’ en la mónada actual.  Todas las
     expresiones en la secuencia deben ser expresiones monádicas.

 -- Sistema Scheme: munless CONDICIÓN MEXP0 MEXP* ...
     Cuando CONDICIÓN es falso, evalúa la secuencia de expresiones
     monádicas MEXP0..MEXP* como dentro de ‘mbegin’.  Cuando CONDICIÓN
     es verdadero, devuelve ‘*unespecified*’ en la mónada actual.  Todas
     las expresiones en la secuencia deben ser expresiones monádicas.

   El módulo ‘(guix monads)’ proporciona la “mónada de estado”, que
permite que un valor adicional—el estado—sea _hilado_ a través de las
llamadas a procedimientos monádicos.

 -- Variable Scheme: %state-monad
     La mónada de estado.  Procedimientos en la mónada de estado pueden
     acceder y cambiar el estado hilado.

     Considere el siguiente ejemplo.  El procedimiento ‘cuadrado’
     devuelve un valor en la mónada de estado.

          (define (cuadrado x)
            (mlet %state-monad ((count (current-state)))
              (mbegin %state-monad
                (set-current-state (+ 1 count))
                (return (* x x)))))

          (run-with-state (sequence %state-monad (map cuadrado (iota 3))) 0)
          ⇒ (0 1 4)
          ⇒ 3

     Cuando se “ejecuta” a través de ‘%state-monad’, obtenemos un valor
     adicional de estado, que es el número de llamadas a ‘cuadrado’.

 -- Procedimiento monádico: current-state
     Devuelve el estado actual como un valor monádico.

 -- Procedimiento monádico: set-current-state VALOR
     Establece el estado actual a VALOR y devuelve el estado previo como
     un valor monádico.

 -- Procedimiento monádico: state-push VALOR
     Apila VALOR al estado actual, que se asume que es una lista, y
     devuelve el estado previo como un valor monádico.

 -- Procedimiento monádico: state-pop
     Extrae un valor del estado actual y lo devuelve como un valor
     monádico.  Se asume que el estado es una lista.

 -- Procedimiento Scheme: run-with-state MVAL [ESTADO]
     Ejecuta un valor monádico MVAL comenzando con ESTADO como el estado
     inicial.  Devuelve dos valores: el valor resultante y el estado
     resultante.

   La interfaz principal a la mónada del almacén, proporcionada por el
módulo ‘(guix store)’, es como sigue.

 -- Variable Scheme: %store-monad
     La mónada del almacén—un alias para ‘%state-monad’.

     Los valores en la mónada del almacén encapsulan los accesos al
     almacén.  Cuando su efecto es necesario, un valor de la mónada del
     almacén será “evaluado” cuando se proporcione al procedimiento
     ‘run-with-store’ (véase a continuación).

 -- Procedimiento Scheme: run-with-store ALMACÉN MVAL
          [#:guile-for-build] [#:system (%current-system)]
     Ejecuta MVAL, un valor monádico en la mónada del almacén, en
     ALMACÉN, una conexión abierta al almacén.

 -- Procedimiento monádico: text-file NOMBRE TEXTO [REFERENCIAS]
     Devuelve como un valor monádico el nombre absoluto del archivo en
     el almacén del archivo que contiene ŦEXTO, una cadena.  REFERENCIAS
     es una lista de elementos del almacén a los que el archivo de texto
     referencia; su valor predeterminado es la lista vacía.

 -- Procedimiento monádico: binary-file NOMBRE DATOS [REFERENCIAS]
     Devuelve como un valor monádico el nombre absoluto del archivo en
     el almacén del archivo que contiene DATOS, un vector de bytes.
     REFERENCIAS es una lista de elementos del almacén a los que el
     archivo binario referencia; su valor predeterminado es la lista
     vacía.

 -- Procedimiento monádico: interned-file ARCHIVO [NOMBRE] [#:recursive?
          #t] [#:select? (const #t)]
     Devuelve el nombre del ARCHIVO una vez internado en el almacén.
     Usa NOMBRE como su nombre del almacén, o el nombre base de ARCHIVO
     si NOMBRE se omite.

     Cuando RECURSIVE? es verdadero, los contenidos del ARCHIVO se
     añaden recursivamente; si ARCHIVO designa un archivo plano y
     RECURSIVE? es verdadero, sus contenidos se añaden, y sus bits de
     permisos se mantienen.

     Cuando RECURSIVE? es verdadero, llama a ‘(SELECT? ARCHIVO STAT)’
     por cada entrada del directorio, donde ARCHIVO es el nombre
     absoluto de archivo de la entrada y STAT es el resultado de
     ‘lstat’; excluyendo las entradas para las cuales SELECT? no
     devuelve verdadero.

     El ejemplo siguiente añade un archivo al almacén, bajo dos nombres
     diferentes:

          (run-with-store (open-connection)
            (mlet %store-monad ((a (interned-file "README"))
                                (b (interned-file "README" "LEGU-MIN")))
              (return (list a b))))

          ⇒ ("/gnu/store/rwm...-README" "/gnu/store/44i...-LEGU-MIN")

   El módulo ‘(guix packages)’ exporta los siguientes procedimientos
monádicos relacionados con paquetes:

 -- Procedimiento monádico: package-file PAQUETE [ARCHIVO] [#:system
          (%current-system)] [#:target #f] [#:output "out"]
     Devuelve como un valor monádico el nombre absoluto de archivo de
     ARCHIVO dentro del directorio de salida OUTPUT del PAQUETE.  Cuando
     se omite ARCHIVO, devuelve el nombre del directorio de salida
     OUTPUT del PAQUETE.  Cuando TARGET es verdadero, se usa como una
     tripleta de compilación cruzada.

     Tenga en cuenta que este procedimiento _no_ construye PAQUETE.  Por
     lo tanto, el resultado puede designar o no un archivo existente.
     Le recomendamos que no use este procedimiento a no ser que sepa qué
     está haciendo.

 -- Procedimiento monádico: package->derivation PAQUETE [SISTEMA]
 -- Procedimiento monádico: package->cross-derivation PAQUETE OBJETIVO
          [SISTEMA]
     Versión monádica de ‘package-derivation’ y
     ‘package-cross-derivation’ (*note Definición de paquetes::).

   ---------- Footnotes ----------

   (1) Esta operación es habitualmente conocida como “bind”
(asociación), pero ese nombre denota un procedimiento no relacionado en
Guile.  Por tanto usamos este símbolo en cierto modo críptico heredado
del lenguaje Haskell.


File: guix.es.info,  Node: Expresiones-G,  Next: Invocación de guix repl,  Prev: La mónada del almacén,  Up: Interfaz programática

9.12 Expresiones-G
==================

Por tanto tenemos “derivaciones”, que representan una secuencia de
acciones de construcción a realizar para producir un elemento en el
almacén (*note Derivaciones::).  Estas acciones de construcción se
llevan a cabo cuando se solicita al daemon construir realmente la
derivación; se ejecutan por el daemon en un contenedor (*note Invocación
de guix-daemon::).

   No debería ser ninguna sorpresa que nos guste escribir estas acciones
de construcción en Scheme.  Cuando lo hacemos, terminamos con dos
“estratos” de código Scheme(1): el “código anfitrión”—código que define
paquetes, habla al daemon, etc.—y el “código de construcción”—código que
realmente realiza las acciones de construcción, como la creación de
directorios, la invocación de ‘make’, etcétera (*note Fases de
construcción::).

   Para describir una derivación y sus acciones de construcción,
típicamente se necesita embeber código de construcción dentro del código
anfitrión.  Se resume en la manipulación de código de construcción como
datos, y la homoiconicidad de Scheme—el código tiene representación
directa como datos—es útil para ello.  Pero necesitamos más que el
mecanismo normal de ‘quasiquote’ en Scheme para construir expresiones de
construcción.

   El módulo ‘(guix gexp)’ implementa las “expresiones-G”, una forma de
expresiones-S adaptada para expresiones de construcción.  Las
expresiones-G, o “gexps”, consiste esencialmente en tres formas
sintácticas: ‘gexp’, ‘ungexp’ y ‘ungexp-splicing’ (o simplemente: ‘#~’,
‘#$’ y ‘#$@’), que son comparables a ‘quasiquote’, ‘unquote’ y
‘unquote-splicing’, respectivamente (*note ‘quasiquote’:
(guile)Expression Syntax.).  No obstante, hay importantes diferencias:

   • Las expresiones-G están destinadas a escribirse en un archivo y ser
     ejecutadas o manipuladas por otros procesos.

   • Cuando un objeto de alto nivel como un paquete o una derivación se
     expande dentro de una expresión-G, el resultado es el mismo que la
     introducción de su nombre de archivo de salida.

   • Las expresiones-G transportan información acerca de los paquetes o
     derivaciones que referencian, y estas referencias se añaden
     automáticamente como entradas al proceso de construcción que las
     usa.

   Este mecanismo no se limita a objetos de paquete ni derivación:
pueden definirse “compiladores” capaces de “bajar el nivel” de otros
objetos de alto nivel a derivaciones o archivos en el almacén, de modo
que esos objetos puedan introducirse también en expresiones-G. Por
ejemplo, un tipo útil de objetos de alto nivel que pueden insertarse en
una expresión-G son los “objetos tipo-archivo”, los cuales facilitan la
adición de archivos al almacén y su referencia en derivaciones y demás
(vea ‘local-file’ y ‘plain-file’ más adelante).

   Para ilustrar la idea, aquí está un ejemplo de expresión-G:

     (define exp-construccion
       #~(begin
           (mkdir #$output)
           (chdir #$output)
           (symlink (string-append #$coreutils "/bin/ls")
                    "enumera-archivos")))

   Esta expresión-G puede pasarse a ‘gexp->derivation’; obtenemos una
derivación que construye un directorio que contiene exactamente un
enlace simbólico a ‘/gnu/store/...-coreutils-8.22/bin/ls’:

     (gexp->derivation "la-cosa" exp-construccion)

   Como se puede esperar, la cadena ‘"/gnu/store/...-coreutils-8.22"’ se
sustituye por la referencia al paquete COREUTILS en el código de
construcción real, y COREUTILS se marca automáticamente como una entrada
a la derivación.  Del mismo modo, ‘#$output’ (equivalente a ‘(ungexp
output)’) se reemplaza por una cadena que contiene el nombre del
directorio de la salida de la derivación.

   En un contexto de compilación cruzada, es útil distinguir entre
referencias a construcciones _nativas_ del paquete—que pueden ejecutarse
en el sistema anfitrión—de referencias de compilaciones cruzadas de un
paquete.  Para dicho fin, ‘#+’ tiene el mismo papel que ‘#$’, pero es
una referencia a una construcción nativa del paquete:

     (gexp->derivation "vi"
        #~(begin
            (mkdir #$output)
            (mkdir (string-append #$output "/bin"))
            (system* (string-append #+coreutils "/bin/ln")
                     "-s"
                     (string-append #$emacs "/bin/emacs")
                     (string-append #$output "/bin/vi")))
        #:target "aarch64-linux-gnu")

En el ejemplo previo, se usa la construcción nativa de COREUTILS, de
modo que ‘ln’ pueda realmente ejecutarse en el anfitrión; pero se hace
referencia a la construcción de compilación cruzada de EMACS.

   Otra característica de las expresiones-G son los “módulos
importados”: a veces deseará ser capaz de usar determinados módulos
Guile del “entorno anfitrión” en la expresión-G, de modo que esos
módulos deban ser importados en el “entorno de construcción”.  La forma
‘with-imported-modules’ le permite expresarlo:

     (let ((build (with-imported-modules '((guix build utils))
                    #~(begin
                        (use-modules (guix build utils))
                        (mkdir-p (string-append #$output "/bin"))))))
       (gexp->derivation "directorio-vacio"
                         #~(begin
                             #$build
                             (display "éxito!\n")
                             #t)))

En este ejemplo, el módulo ‘(guix build utils)’ se incorpora
automáticamente dentro del entorno de construcción aislado de nuestra
expresión-G, de modo que ‘(use-modules (guix build utils))’ funciona
como se espera.

   De manera habitual deseará que la _clausura_ del módulo se importe—es
decir, el módulo en sí y todos los módulos de los que depende—en vez del
módulo únicamente; si no se hace, cualquier intento de uso del módulo
fallará porque faltan módulos dependientes.  El procedimiento
‘source-module-closure’ computa la clausura de un módulo mirando en las
cabeceras de sus archivos de fuentes, lo que es útil en este caso:

     (use-modules (guix modules))   ;para 'source-module-closure'

     (with-imported-modules (source-module-closure
                              '((guix build utils)
                                (gnu build image)))
       (gexp->derivation "something-with-vms"
                         #~(begin
                             (use-modules (guix build utils)
                                          (gnu build image))
                             ...)))

   De la misma manera, a veces deseará importar no únicamente módulos
puros de Scheme, pero también “extensiones” como enlaces Guile a
bibliotecas C u otros paquetes “completos”.  Si, digamos, necesitase el
paquete ‘guile-json’ disponible en el lado de construcción, esta sería
la forma de hacerlo:

     (use-modules (gnu packages guile))  ;para 'guile-json'

     (with-extensions (list guile-json)
       (gexp->derivation "algo-con-json"
                         #~(begin
                             (use-modules (json))
                             ...)))

   La forma sintáctica para construir expresiones-G se resume a
continuación.

 -- Sintaxis Scheme: #~EXP
 -- Sintaxis Scheme: (gexp EXP)
     Devuelve una expresión-G que contiene EXP.  EXP puede contener una
     o más de las siguientes formas:

     ‘#$OBJ’
     ‘(ungexp OBJ)’
          Introduce una referencia a OBJ.  OBJ puede tener uno de los
          tipos permitidos, por ejemplo un paquete o derivación, en cuyo
          caso la forma ‘ungexp’ se substituye por el nombre de archivo
          de su salida—por ejemplo, ‘"/gnu/store/...-coreutils-8.22’.

          Si OBJ es una lista, se recorre y las referencias a objetos
          permitidos se substituyen de manera similar.

          Si OBJ es otra expresión-G, su contenido se inserta y sus
          dependencias se añaden a aquellas de la expresión-G que la
          contiene.

          Si OBJ es otro tipo de objeto, se inserta tal cual es.

     ‘#$OBJ:SALIDA’
     ‘(ungexp OBJ SALIDA)’
          Como la forma previa, pero referenciando explícitamente la
          SALIDA de OBJ—esto es útil cuando OBJ produce múltiples
          salidas (*note Paquetes con múltiples salidas::).

     ‘#+OBJ’
     ‘#+OBJ:salida’
     ‘(ungexp-native OBJ)’
     ‘(ungexp-native OBJ SALIDA)’
          Igual que ‘ungexp’, pero produce una referencia a la
          construcción _nativa_ de OBJ cuando se usa en un contexto de
          compilación cruzada.

     ‘#$output[:SALIDA]’
     ‘(ungexp output [SALIDA])’
          Inserta una referencia a la salida de la derivación SALIDA, o
          a la salida principal cuando SALIDA se omite.

          Esto únicamente tiene sentido para expresiones-G pasadas a
          ‘gexp->derivation’.

     ‘#$@LST’
     ‘(ungexp-splicing LST)’
          Lo mismo que la forma previa, pero expande el contenido de la
          lista LST como parte de la lista que la contiene.

     ‘#+@LST’
     ‘(ungexp-native-splicing LST)’
          Lo mismo que la forma previa, pero hace referencia a las
          construcciones nativas de los objetos listados en LST.

     Las expresiones-G creadas por ‘gexp’ o ‘#~’ son objetos del tipo
     ‘gexp?’ en tiempo de ejecución (véase a continuación).

 -- Sintaxis Scheme: with-imported-modules MÓDULOS CUERPO...
     Marca las expresiones-G definidas en el CUERPO... como si
     requiriesen MÓDULOS en su entorno de ejecución.

     Cada elemento en MÓDULOS puede ser el nombre de un módulo, como
     ‘(guix build utils)’, o puede ser el nombre de un módulo, seguido
     de una flecha, seguido de un objeto tipo-archivo:

          `((guix build utils)
            (guix gcrypt)
            ((guix config) => ,(scheme-file "config.scm"
                                            #~(define-module ...))))

     En el ejemplo previo, los dos primeros módulos se toman de la ruta
     de búsqueda, y el último se crea desde el objeto tipo-archivo
     proporcionado.

     Esta forma tiene ámbito _léxico_: tiene efecto en las expresiones-G
     definidas en CUERPO..., pero no en aquellas definidas, digamos, en
     procedimientos llamados por CUERPO....

 -- Sintaxis Scheme: with-extensions EXTENSIONES CUERPO...
     Marca que las expresiones definidas en CUERPO... requieren
     EXTENSIONES en su entorno de construcción y ejecución.  EXTENSIONES
     es típicamente una lista de objetos de paquetes como los que se
     definen en el módulo ‘(gnu packages guile)’.

     De manera concreta, los paquetes listados en EXTENSIONES se añaden
     a la ruta de carga mientras se compilan los módulos importados en
     CUERPO...; también se añaden a la ruta de carga en la expresión-G
     devuelta por CUERPO....

 -- Procedimiento Scheme: gexp? OBJ
     Devuelve ‘#t’ si OBJ es una expresión-G.

   Las expresiones-G están destinadas a escribirse en disco, tanto en
código que construye alguna derivación, como en archivos planos en el
almacén.  Los procedimientos monádicos siguientes le permiten hacerlo
(*note La mónada del almacén::, para más información sobre mónadas).

 -- Procedimiento monádico: gexp->derivation NOMBRE EXP [#:system
          (%current-system)] [#:target #f] [#:graft? #t] [#:hash #f]
          [#:hash-algo #f] [#:recursive? #f] [#:env-vars '()] [#:modules
          '()] [#:module-path ‘%load-path’] [#:effective-version "2.2"]
          [#:references-graphs #f] [#:allowed-references #f]
          [#:disallowed-references #f] [#:leaked-env-vars #f]
          [#:script-name (string-append NOMBRE "-builder")]
          [#:deprecation-warnings #f] [#:local-build? #f]
          [#:substitutable? #t] [#:properties '()] [#:guile-for-build
          #f]
     Devuelve una derivación NOMBRE que ejecuta EXP (una expresión-G)
     con GUILE-FOR-BUILD (una derivación) en el sistema SYSTEM; EXP se
     almacena en un archivo llamado SCRIPT-NAME.  Cuando TARGET tiene
     valor verdadero, se usa como tripleta de compilación cruzada para
     paquetes a los que haga referencia EXP.

     MODULES está obsoleto en favor de ‘with-imported-modules’.  Su
     significado es hacer que los módulos MODULES estén disponibles en
     el contexto de evaluación de EXP; MODULES es una lista de nombres
     de módulos Guile buscados en MODULE-PATH para ser copiados al
     almacén, compilados y disponibles en la ruta de carga durante la
     ejecución de EXP—por ejemplo, ‘((guix build utils) (gui build
     gnu-build-system))’.

     EFFECTIVE-VERSION determina la cadena usada cuando se añaden las
     extensiones de EXP (vea ‘with-extensions’) a la ruta de
     búsqueda—por ejemplo, ‘"2.2"’.

     GRAFT? determina si los paquetes a los que EXP hace referencia
     deben ser injertados cuando sea posible.

     Cuando REFERENCES-GRAPHS es verdadero, debe ser una lista de tuplas
     de una de las formas siguientes:

          (NOMBRE-ARCHIVO PAQUETE)
          (NOMBRE-ARCHIVO PAQUETE SALIDA)
          (NOMBRE-ARCHIVO DERIVACIÓN)
          (NOMBRE-ARCHIVO DERIVACIÓN SALIDA)
          (NOMBRE-ARCHIVO ELEMENTO-ALMACÉN)

     El lado derecho de cada elemento de REFERENCES-GRAPHS se convierte
     automáticamente en una entrada del proceso de construcción de EXP.
     En el entorno de construcción, cada NOMBRE-ARCHIVO contiene el
     grafo de referencias del elemento correspondiente, en un formato de
     texto simple.

     ALLOWED-REFERENCES debe ser o bien ‘#f’ o una lista de nombres y
     paquetes de salida.  En el último caso, la lista denota elementos
     del almacén a los que el resultado puede hacer referencia.
     Cualquier referencia a otro elemento del almacén produce un error
     de construcción.  De igual manera con DISALLOWED-REFERENCES, que
     enumera elementos a los que las salidas no deben hacer referencia.

     DEPRECATION-WARNINGS determina si mostrar avisos de obsolescencia
     durante la compilación de los módulos.  Puede ser ‘#f’, ‘#t’ o
     ‘'detailed’.

     El resto de parámetros funcionan como en ‘derivation’ (*note
     Derivaciones::).

   Los procedimientos ‘local-file’, ‘plain-file’, ‘computed-file’,
‘program-file’ y ‘scheme-file’ a continuación devuelven “objetos
tipo-archivo”.  Esto es, cuando se expanden en una expresión-G, estos
objetos dirigen a un archivo en el almacén.  Considere esta expresión-G:

     #~(system* #$(file-append glibc "/sbin/nscd") "-f"
                #$(local-file "/tmp/mi-nscd.conf"))

   El efecto aquí es el “internamiento” de ‘/tmp/mi-nscd.conf’ mediante
su copia al almacén.  Una vez expandida, por ejemplo vía
‘gexp->derivation’, la expresión-G hace referencia a la copia bajo
‘/gnu/store’; por tanto, la modificación o el borrado del archivo en
‘/tmp’ no tiene ningún efecto en lo que la expresión-G hace.
‘plain-file’ puede usarse de manera similar; se diferencia en que el
contenido del archivo se proporciona directamente como una cadena.

 -- Procedimiento Scheme: local-file ARCHIVO [NOMBRE] [#:recursive? #f]
          [#:select? (const #t)]
     Devuelve un objeto que representa el archivo local ARCHIVO a añadir
     al almacén; este objeto puede usarse en una expresión-G. Si ARCHIVO
     es un nombre de archivo relativo, se busca de forma relativa al
     archivo fuente donde esta forma aparece; si ARCHIVO no es una
     cadena literal, se buscará de manera relativa al directorio de
     trabajo durante la ejecución.  ARCHIVO se añadirá al almacén bajo
     NOMBRE—de manera predeterminada el nombre de ARCHIVO sin los
     directorios.

     Cuando RECURSIVE? es verdadero, los contenidos del ARCHIVO se
     añaden recursivamente; si ARCHIVO designa un archivo plano y
     RECURSIVE? es verdadero, sus contenidos se añaden, y sus bits de
     permisos se mantienen.

     Cuando RECURSIVE? es verdadero, llama a ‘(SELECT? ARCHIVO STAT)’
     por cada entrada del directorio, donde ARCHIVO es el nombre
     absoluto de archivo de la entrada y STAT es el resultado de
     ‘lstat’; excluyendo las entradas para las cuales SELECT? no
     devuelve verdadero.

     Esta es la contraparte declarativa del procedimiento monádico
     ‘interned-file’ (*note ‘interned-file’: La mónada del almacén.).

 -- Procedimiento Scheme: plain-file NOMBRE CONTENIDO
     Devuelve un objeto que representa un archivo de texto llamado
     NOMBRE con el CONTENIDO proporcionado (una cadena o un vector de
     bytes) para ser añadido al almacén.

     Esta es la contraparte declarativa de ‘text-file’.

 -- Procedimiento Scheme: computed-file NOMBRE GEXP [#:local-build? #t]
          [#:options '()]
     Devuelve un objeto que representa el elemento del almacén NOMBRE,
     un archivo o un directorio computado por GEXP.  Cuando LOCAL-BUILD?
     tiene valor verdadero (el caso predeterminado), la derivación se
     construye de manera local.  OPTIONS es una lista de parámetros
     adicionales proporcionados a ‘gexp->derivation’.

     Esta es la contraparte declarativa de ‘gexp->derivation’.

 -- Procedimiento monádico: gexp->script NOMBRE EXP [#:guile
          (default-guile)] [#:module-path %load-path]  [#:system
     (%current-system)] [#:target #f] Devuelve un guión ejecutable
     NOMBRE que ejecuta EXP usando GUILE, con los módulos importados por
     EXP en su ruta de búsqueda.  Busca los módulos de EXP en
     MODULE-PATH.

     El ejemplo siguiente construye un guión que simplemente invoca la
     orden ‘ls’:

          (use-modules (guix gexp) (gnu packages base))

          (gexp->script "enumera-archivos"
                        #~(execl #$(file-append coreutils "/bin/ls")
                                 "ls"))

     Cuando se ejecuta a través del almacén (*note ‘run-with-store’: La
     mónada del almacén.), obtenemos una derivación que produce un
     archivo ejecutable ‘/gnu/store/...-enumera-archivos’ más o menos
     así:

          #!/gnu/store/...-guile-2.0.11/bin/guile -ds
          !#
          (execl "/gnu/store/...-coreutils-8.22"/bin/ls" "ls")

 -- Procedimiento Scheme: program-file NOMBRE EXP [#:guile #f]
          [#:module-path %load-path]
     Devuelve un objeto que representa el elemento ejecutable del
     almacén NOMBRE que ejecuta GEXP.  GUILE es el paquete Guile usado
     para ejecutar el guión.  Los módulos importados por GEXP se buscan
     en MODULE-PATH.

     Esta es la contraparte declarativa de ‘gexp->script’.

 -- Procedimiento monádico: gexp->file NOMBRE EXP [#:set-load-path? #t]
          [#:module-path %load-path] [#:splice? #f] [#:guile
          (default-guile)]
     Devuelve una derivación que construye un archivo NOMBRE que
     contiene EXP.  Cuando SPLICE? es verdadero, se considera que EXP es
     una lista de expresiones que deben ser expandidas en el archivo
     resultante.

     Cuando SET-LOAD-PATH es verdadero, emite código en el archivo
     resultante para establecer ‘%load-path’ y ‘%load-compiled-path’ de
     manera que respeten los módulos importados por EXP.  Busca los
     módulos de EXP en MODULE-PATH.

     El archivo resultante hace referencia a todas las dependencias de
     EXP o a un subconjunto de ellas.

 -- Procedimiento Scheme: scheme-file NOMBRE EXP [#:splice? #f]
          [#:set-load-path? #t]
     Devuelve un objeto que representa el archivo Scheme NOMBRE que
     contiene EXP.

     Esta es la contraparte declarativa de ‘gexp->file’.

 -- Procedimiento monádico: text-file* NOMBRE TEXTO ...
     Devuelve como un valor monádico una derivación que construye un
     archivo de texto que contiene todo TEXTO.  TEXTO puede ser una
     lista de, además de cadenas, objetos de cualquier tipo que pueda
     ser usado en expresiones-G: paquetes, derivaciones, archivos
     locales, objetos, etc.  El archivo del almacén resultante hace
     referencia a todos ellos.

     Esta variante debe preferirse sobre ‘text-file’ cuando el archivo a
     crear haga referencia a elementos del almacén.  Esto es el caso
     típico cuando se construye un archivo de configuración que embebe
     nombres de archivos del almacén, como este:

          (define (perfil.sh)
            ;; Devuelve el nombre de un guión shell en el almacén
            ;; que establece la variable de entorno 'PATH'
            (text-file* "perfil.sh"
                        "export PATH=" coreutils "/bin:"
                        grep "/bin:" sed "/bin\n"))

     En este ejemplo, el archivo ‘/gnu/store/...-perfil.sh’ resultante
     hará referencia a COREUTILS, GREP y SED, por tanto evitando que se
     recolecten como basura durante su tiempo de vida.

 -- Procedimiento Scheme: mixed-text-file NOMBRE TEXTO ...
     Devuelve un objeto que representa el archivo del almacén NOMBRE que
     contiene TEXTO.  TEXTO es una secuencia de cadenas y objetos
     tipo-archivo, como en:

          (mixed-text-file "perfil"
                           "export PATH=" coreutils "/bin:" grep "/bin")

     Esta es la contraparte declarativa de ‘text-file*’.

 -- Procedimiento Scheme: file-union NOMBRE ARCHIVOS
     Devuelve un ‘<computed-file>’ que construye un directorio que
     contiene todos los ARCHIVOS.  Cada elemento en ARCHIVOS debe ser
     una lista de dos elementos donde el primer elemento es el nombre de
     archivo usado en el nuevo directorio y el segundo elemento es una
     expresión-G que denota el archivo de destino.  Aquí está un
     ejemplo:

          (file-union "etc"
                      `(("hosts" ,(plain-file "hosts"
                                              "127.0.0.1 localhost"))
                        ("bashrc" ,(plain-file "bashrc"
                                               "alias ls='ls --color=auto'"))))

     Esto emite un directorio ‘etc’ que contiene estos dos archivos.

 -- Procedimiento Scheme: directory-union NOMBRE COSAS
     Devuelve un directorio que es la unión de COSAS, donde COSAS es una
     lista de objetos tipo-archivo que denotan directorios.  Por
     ejemplo:

          (directory-union "guile+emacs" (list guile emacs))

     emite un directorio que es la unión de los paquetes ‘guile’ y
     ‘emacs’.

 -- Procedimientos Scheme: file-append OBJ SUFIJO ...
     Devuelve un objeto tipo-archivo que se expande a la concatenación
     de OBJ y SUFIJO, donde OBJ es un objeto que se puede bajar de nivel
     y cada SUFIJO es una cadena.

     Como un ejemplo, considere esta expresión-G:

          (gexp->script "ejecuta-uname"
                        #~(system* #$(file-append coreutils
                                                  "/bin/uname")))

     El mismo efecto podría conseguirse con:

          (gexp->script "ejecuta-uname"
                        #~(system* (string-append #$coreutils
                                                  "/bin/uname")))

     Hay una diferencia no obstante: en el caso de ‘file-append’, el
     guión resultante contiene una ruta absoluta de archivo como una
     cadena, mientras que en el segundo caso, el guión resultante
     contiene una expresión ‘(string-append ...)’ para construir el
     nombre de archivo _en tiempo de ejecución_.

 -- Sintaxis Scheme: let-system SISTEMA CUERPO...
 -- Sintaxis Scheme: let-system (SISTEMA OBJETIVO) CUERPO...
     Asocia SISTEMA al sistema objetivo actual—por ejemplo,
     ‘"x86_64-linux"’—dentro de CUERPO.

     En el segundo caso, asocia también OBJETIVO al objetivo actual de
     compilación cruzada—una tripleta de GNU como
     ‘"arm-linux-gnueabihf"’—o ‘#f’ si no se trata de una compilación
     cruzada.

     ‘let-system’ es útil en el caso ocasional en el que el objeto
     introducido en la expresión-G depende del sistema objetivo, como en
     este ejemplo:

          #~(system*
             #+(let-system system
                 (cond ((string-prefix? "armhf-" system)
                        (file-append qemu "/bin/qemu-system-arm"))
                       ((string-prefix? "x86_64-" system)
                        (file-append qemu "/bin/qemu-system-x86_64"))
                       (else
                        (error "¡ni idea!"))))
             "-net" "user" #$image)

 -- Sintaxis Scheme: with-parameters ((PARÁMETRO VALOR ...) EXP
     Este macro es similar a la forma ‘parameterize’ para “parámetros”
     asociados de forma dinámica (*note (guile)Parameters::).  La
     principal diferencia es que se hace efectivo cuando el objeto
     tipo-archivo devuelto por EXP se baja de nivel a una derivación o
     un elemento del almacén.

     Un uso típico de ‘with-parameters’ es para forzar el sistema
     efectivo de cierto objeto:

          (with-parameters ((%current-system "i686-linux"))
            coreutils)

     El ejemplo previo devuelve un objeto que corresponde a la
     construcción en i686 de Coreutils, independientemente del valor
     actual de ‘%current-system’.

   Por supuesto, además de expresiones-G embebidas en código
“anfitrión”, hay también módulos que contienen herramientas de
construcción.  Para clarificar que están destinados para su uso en el
estrato de construcción, estos módulos se mantienen en el espacio de
nombres ‘(guix build ...)’.

   Internamente, los objetos de alto nivel se “bajan de nivel”, usando
su compilador, a derivaciones o elementos del almacén.  Por ejemplo,
bajar de nivel un paquete emite una derivación, y bajar de nivel un
PLAIN-FILE emite un elemento del almacén.  Esto se consigue usando el
procedimiento monádico ‘lower-object’.

 -- Procedimiento monádico: lower-object OBJ [SISTEMA] [#:target #f]
     Devuelve como un valor en ‘%store-monad’ la derivación o elemento
     del almacén que corresponde a OBJ en SISTEMA, compilando de manera
     cruzada para TARGET si TARGET es verdadero.  OBJ debe ser un objeto
     que tiene asociado un compilador de expresiones-G, como por ejemplo
     un objeto del tipo ‘<package>’.

 -- Procedure: gexp->approximate-sexp GEXP
     Sometimes, it may be useful to convert a G-exp into a S-exp.  For
     example, some linters (*note Invocación de guix lint::) peek into
     the build phases of a package to detect potential problems.  This
     conversion can be achieved with this procedure.  However, some
     information can be lost in the process.  More specifically,
     lowerable objects will be silently replaced with some arbitrary
     object – currently the list ‘(*approximate*)’, but this may change.

   ---------- Footnotes ----------

   (1) El término “estrato” en este contexto se debe a Manuel Serrano et
al. en el contexto de su trabajo en Hop.  Oleg Kiselyov, quien ha
escrito profundos ensayos sobre el tema
(http://okmij.org/ftp/meta-programming/#meta-scheme), se refiere a este
tipo de generación de código como separación en etapas o “staging”.


File: guix.es.info,  Node: Invocación de guix repl,  Next: Using Guix Interactively,  Prev: Expresiones-G,  Up: Interfaz programática

9.13 Invocación de ‘guix repl’
==============================

La orden ‘guix repl’ lanza una “sesión interactiva” Guile (REPL) para la
programación interactiva (*note (guile)Using Guile Interactively::), o
para la ejecución de guiones de Guile.  Comparado a simplemente lanzar
la orden ‘guile’, ‘guix repl’ garantiza que todos los módulos Guix y
todas sus dependencias están disponibles en la ruta de búsqueda.

   La sintaxis general es:

     guix repl OPCIONES [ARCHIVO PARÁMETROS]

   Cuando se proporciona ARCHIVO, ARCHIVO se ejecuta como un guión de
Guile:

     guix repl mi-guion.scm

   Para proporcionar parámetros al guión, use ‘--’ para evitar que se
interpreten como parámetros específicos de ‘guix repl’:

     guix repl -- mi-guion.scm --input=foo.txt

   Pare hacer que un guión sea ejecutable directamente desde el shell,
mediante el uso del ejecutable de guix que se encuentre en la ruta de
búsqueda de la usuaria, escriba las siguientes dos líneas al inicio del
archivo:

     #!/usr/bin/env -S guix repl --
     !#

   Without a file name argument, a Guile REPL is started, allowing for
interactive use (*note Using Guix Interactively::):

     $ guix repl
     scheme@(guile-user)> ,use (gnu packages base)
     scheme@(guile-user)> coreutils
     $1 = #<package coreutils@8.29 gnu/packages/base.scm:327 3e28300>

   Además, ‘guix repl’ implementa un protocolo del REPL simple legible
por máquinas para su uso por ‘(guix inferior)’, una facilidad para
interactuar con “inferiores”, procesos separados que ejecutan una
revisión de Guix potencialmente distinta.

   Las opciones disponibles son las siguientes:

‘--type=TIPO’
‘-t TIPO’
     Inicia un REPL del TIPO dado, que puede ser uno de los siguientes:

     ‘guile’
          Es el predeterminado, y lanza una sesión interactiva Guile
          estándar con todas las características.
     ‘machine’
          Lanza un REPL que usa el protocolo legible por máquinas.  Este
          es el protocolo con el que el módulo ‘(guix inferior)’ se
          comunica.

‘--listen=DESTINO’
     Por defecto, ‘guix repl’ lee de la entrada estándar y escribe en la
     salida estándar.  Cuando se pasa esta opción, en vez de eso
     escuchará las conexiones en DESTINO.  Estos son ejemplos de
     opciones válidas:

     ‘--listen=tcp:37146’
          Acepta conexiones locales por el puerto 37146.

     ‘--listen=unix:/tmp/socket’
          Acepta conexiones a través del socket de dominio Unix
          ‘/tmp/socket’.

‘--load-path=DIRECTORIO’
‘-L DIRECTORIO’
     Añade DIRECTORIO al frente de la ruta de búsqueda de módulos de
     paquetes (*note Módulos de paquetes::).

     Esto permite a las usuarias definir sus propios paquetes y hacerlos
     visibles al guión o a la sesión interactiva.

‘-q’
     Inhibe la carga del archivo ‘~/.guile’.  De manera predeterminada,
     dicho archivo de configuración se carga al lanzar una sesión
     interactiva de ‘guile’.


File: guix.es.info,  Node: Using Guix Interactively,  Prev: Invocación de guix repl,  Up: Interfaz programática

9.14 Using Guix Interactively
=============================

The ‘guix repl’ command gives you access to a warm and friendly
“read-eval-print loop” (REPL) (*note Invocación de guix repl::).  If
you’re getting into Guix programming—defining your own packages, writing
manifests, defining services for Guix System or Guix Home, etc.—you will
surely find it convenient to toy with ideas at the REPL.

   If you use Emacs, the most convenient way to do that is with Geiser
(*note La configuración perfecta::), but you do not have to use Emacs to
enjoy the REPL.  When using ‘guix repl’ or ‘guile’ in the terminal, we
recommend using Readline for completion and Colorized to get colorful
output.  To do that, you can run:

     guix install guile guile-readline guile-colorized

...  and then create a ‘.guile’ file in your home directory containing
this:

     (use-modules (ice-9 readline) (ice-9 colorized))

     (activate-readline)
     (activate-colorized)

   The REPL lets you evaluate Scheme code; you type a Scheme expression
at the prompt, and the REPL prints what it evaluates to:

     $ guix repl
     scheme@(guix-user)> (+ 2 3)
     $1 = 5
     scheme@(guix-user)> (string-append "a" "b")
     $2 = "ab"

   It becomes interesting when you start fiddling with Guix at the REPL.
The first thing you’ll want to do is to “import” the ‘(guix)’ module,
which gives access to the main part of the programming interface, and
perhaps a bunch of useful Guix modules.  You could type ‘(use-modules
(guix))’, which is valid Scheme code to import a module (*note
(guile)Using Guile Modules::), but the REPL provides the ‘use’ “command”
as a shorthand notation (*note (guile)REPL Commands::):

     scheme@(guix-user)> ,use (guix)
     scheme@(guix-user)> ,use (gnu packages base)

   Notice that REPL commands are introduced by a leading comma.  A REPL
command like ‘use’ is not valid Scheme code; it’s interpreted specially
by the REPL.

   Guix extends the Guile REPL with additional commands for convenience.
Among those, the ‘build’ command comes in handy: it ensures that the
given file-like object is built, building it if needed, and returns its
output file name(s).  In the example below, we build the ‘coreutils’ and
‘grep’ packages, as well as a “computed file” (*note ‘computed-file’:
Expresiones-G.), and we use the ‘scandir’ procedure to list the files in
Grep’s ‘/bin’ directory:

     scheme@(guix-user)> ,build coreutils
     $1 = "/gnu/store/...-coreutils-8.32-debug"
     $2 = "/gnu/store/...-coreutils-8.32"
     scheme@(guix-user)> ,build grep
     $3 = "/gnu/store/...-grep-3.6"
     scheme@(guix-user)> ,build (computed-file "x" #~(mkdir #$output))
     building /gnu/store/...-x.drv...
     $4 = "/gnu/store/...-x"
     scheme@(guix-user)> ,use(ice-9 ftw)
     scheme@(guix-user)> (scandir (string-append $3 "/bin"))
     $5 = ("." ".." "egrep" "fgrep" "grep")

   At a lower-level, a useful command is ‘lower’: it takes a file-like
object and “lowers” it into a derivation (*note Derivaciones::) or a
store file:

     scheme@(guix-user)> ,lower grep
     $6 = #<derivation /gnu/store/...-grep-3.6.drv => /gnu/store/...-grep-3.6 7f0e639115f0>
     scheme@(guix-user)> ,lower (plain-file "x" "Hello!")
     $7 = "/gnu/store/...-x"

   The full list of REPL commands can be seen by typing ‘,help guix’ and
is given below for reference.

 -- REPL command: build OBJECT
     Lower OBJECT and build it if it’s not already built, returning its
     output file name(s).

 -- REPL command: lower OBJECT
     Lower OBJECT into a derivation or store file name and return it.

 -- REPL command: verbosity LEVEL
     Change build verbosity to LEVEL.

     This is similar to the ‘--verbosity’ command-line option (*note
     Opciones comunes de construcción::): level 0 means total silence,
     level 1 shows build events only, and higher levels print build
     logs.

 -- REPL command: run-in-store EXP
     Run EXP, a monadic expresssion, through the store monad.  *Note La
     mónada del almacén::, for more information.

 -- REPL command: enter-store-monad
     Enter a new REPL to evaluate monadic expressions (*note La mónada
     del almacén::).  You can quit this “inner” REPL by typing ‘,q’.


File: guix.es.info,  Node: Utilidades,  Next: Foreign Architectures,  Prev: Interfaz programática,  Up: Top

10 Utilidades
*************

Esta sección describe las utilidades de línea de órdenes de Guix.
Algunas de ellas están orientadas principalmente para desarrolladoras y
usuarias que escriban definiciones de paquetes nuevas, mientras que
otras son útiles de manera más general.  Complementan la interfaz
programática Scheme de Guix de modo conveniente.

* Menu:

* Invocación de guix build::  Construir paquetes desde la línea de
                                 órdenes.
* Invocación de guix edit::  Editar las definiciones de paquetes.
* Invocación de guix download::  Descargar un archivo e imprimir su hash.
* Invocación de guix hash::  Calcular el hash criptográfico de un archivo.
* Invocación de guix import::  Importar definiciones de paquetes.
* Invocación de guix refresh::  Actualizar definiciones de paquetes.
* Invoking guix style::      Styling package definitions.
* Invocación de guix lint::  Encontrar errores en definiciones de paquetes.
* Invocación de guix size::  Perfilar el uso del disco.
* Invocación de guix graph::  Visualizar el grafo de paquetes.
* Invocación de guix publish::  Compartir sustituciones.
* Invocación de guix challenge::  Poner a prueba servidores de
                                     sustituciones.
* Invocación de guix copy::  Copiar a y desde un almacén remoto.
* Invocación de guix container::  Aislamiento de procesos.
* Invocación de guix weather::  Comprobar la disponibilidad de
                                   sustituciones.
* Invocación de guix processes::  Enumerar los procesos cliente.


File: guix.es.info,  Node: Invocación de guix build,  Next: Invocación de guix edit,  Up: Utilidades

10.1 Invocación de ‘guix build’
===============================

La orden ‘guix build’ construye paquetes o derivaciones y sus
dependencias, e imprime las rutas del almacén resultantes.  Fíjese que
no modifica el perfil de la usuaria—este es el trabajo de la orden ‘guix
package’ (*note Invocación de guix package::).  Por tanto, es útil
principalmente para las desarrolladoras de la distribución.

   La sintaxis general es:

     guix build OPCIONES PAQUETE-O-DERIVACIÓN...

   Como ejemplo, la siguiente orden construye las últimas versiones de
Emacs y Guile, muestra sus log de construcción, y finalmente muestra los
directorios resultantes:

     guix build emacs guile

   De forma similar, la siguiente orden construye todos los paquetes
disponibles:

     guix build --quiet --keep-going \
       $(guix package -A | awk '{ print $1 "@" $2 }')

   PAQUETE-O-DERIVACIÓN puede ser tanto el nombre de un paquete que se
encuentra en la distribución de software como ‘coreutils’ o
‘coreutils@8.20’, o una derivación como
‘/gnu/store/...-coreutils-8.19.drv’.  En el primer caso, el paquete de
nombre (y opcionalmente versión) correspondiente se busca entre los
módulos de la distribución GNU (*note Módulos de paquetes::).

   De manera alternativa, la opción ‘--expression’ puede ser usada para
especificar una expresión Scheme que evalúa a un paquete; esto es útil
para diferenciar entre varios paquetes con el mismo nombre o si se
necesitan variaciones del paquete.

   Puede haber cero o más OPCIONES.  Las opciones disponibles se
describen en la subsección siguiente.

* Menu:

* Opciones comunes de construcción::  Opciones de construcción para la
                                         mayoría de órdenes.
* Opciones de transformación de paquetes::  Crear variantes de paquetes.
* Opciones de construcción adicionales::  Opciones específicas de ’guix
                                             build’.
* Depuración de fallos de construcción::  Experiencia de empaquetamiento
                                              en la vida real.


File: guix.es.info,  Node: Opciones comunes de construcción,  Next: Opciones de transformación de paquetes,  Up: Invocación de guix build

10.1.1 Opciones comunes de construcción
---------------------------------------

Un número de opciones que controlan el proceso de construcción son
comunes a ‘guix build’ y otras órdenes que pueden lanzar construcciones,
como ‘guix package’ o ‘guix archive’.  Son las siguientes:

‘--load-path=DIRECTORIO’
‘-L DIRECTORIO’
     Añade DIRECTORIO al frente de la ruta de búsqueda de módulos de
     paquetes (*note Módulos de paquetes::).

     Esto permite a las usuarias definir sus propios paquetes y hacerlos
     visibles a las herramientas de línea de órdenes.

‘--keep-failed’
‘-K’
     Mantiene los árboles de construcción de las construcciones
     fallidas.  Por tanto, si una construcción falla, su árbol de
     construcción se mantiene bajo ‘/tmp’, en un directorio cuyo nombre
     se muestra al final del log de construcción.  Esto es útil cuando
     se depuran problemas en la construcción.  *Note Depuración de
     fallos de construcción::, para trucos y consejos sobre cómo depurar
     problemas en la construcción.

     Esta opción implica ‘--no-offload’, y no tiene efecto cuando se
     conecta a un daemon remoto con una URI ‘guix://’ (*note la variable
     ‘GUIX_DAEMON_SOCKET’: El almacén.).

‘--keep-going’
‘-k’
     Seguir adelante cuando alguna de las derivaciones de un fallo
     durante la construcción; devuelve una única vez todas las
     construcciones que se han completado o bien han fallado.

     El comportamiento predeterminado es parar tan pronto una de las
     derivaciones especificadas falle.

‘--dry-run’
‘-n’
     No construye las derivaciones.

‘--fallback’
     Cuando la sustitución de un binario preconstruido falle, intenta la
     construcción local de paquetes (*note Fallos en las
     sustituciones::).

‘--substitute-urls=URLS’
     Considera URLS la lista separada por espacios de URLs de fuentes de
     sustituciones, anulando la lista predeterminada de URLs de
     ‘guix-daemon’ (*note ‘guix-daemon URLs’: daemon-substitute-urls.).

     Significa que las sustituciones puede ser descargadas de URLS,
     mientras que estén firmadas por una clave autorizada por la
     administradora del sistema (*note Sustituciones::).

     Cuando URLS es la cadena vacía, las sustituciones están
     efectivamente desactivadas.

‘--no-substitutes’
     No usa sustituciones para la construcción de productos.  Esto es,
     siempre realiza las construcciones localmente en vez de permitir la
     descarga de binarios pre-construidos (*note Sustituciones::).

‘--no-grafts’
     No “injerta” paquetes.  En la práctica esto significa que las
     actualizaciones de paquetes disponibles como injertos no se
     aplican.  *Note Actualizaciones de seguridad::, para más
     información sobre los injertos.

‘--rounds=N’
     Construye cada derivación N veces seguidas, y lanza un error si los
     resultados de las construcciones consecutivas no son idénticos
     bit-a-bit.

     Esto es útil para la detección de procesos de construcción
     no-deterministas.  Los procesos de construcción no-deterministas
     son un problema puesto que prácticamente imposibilitan a las
     usuarias la _verificación_ de la autenticidad de binarios
     proporcionados por terceras partes.  *Note Invocación de guix
     challenge::, para más sobre esto.

     Cuando se usa conjuntamente con ‘--keep-failed’, la salida que
     difiere se mantiene en el almacén, bajo ‘/gnu/store/...-check’.
     Esto hace fácil buscar diferencias entre los dos resultados.

‘--no-offload’
     No usa la delegación de construcciones en otras máquinas (*note
     Configuración de delegación del daemon::).  Es decir, siempre
     realiza las construcciones de manera local en vez de delegar
     construcciones a máquinas remotas.

‘--max-silent-time=SEGUNDOS’
     Cuando la construcción o sustitución permanece en silencio más de
     SEGUNDOS, la finaliza e informa de un fallo de construcción.

     Por defecto, se respeta la configuración del daemon (*note
     ‘--max-silent-time’: Invocación de guix-daemon.).

‘--timeout=SEGUNDOS’
     Del mismo modo, cuando el proceso de construcción o sustitución
     dura más de SEGUNDOS, lo termina e informa un fallo de
     construcción.

     Por defecto, se respeta la configuración del daemon (*note
     ‘--timeout’: Invocación de guix-daemon.).

‘-v NIVEL’
‘--verbosity=NIVEL’
     Use the given verbosity LEVEL, an integer.  Choosing 0 means that
     no output is produced, 1 is for quiet output; 2 is similar to 1 but
     it additionally displays download URLs; 3 shows all the build log
     output on standard error.

‘--cores=N’
‘-c N’
     Permite usar N núcleos de la CPU para la construcción.  El valor
     especial ‘0’ significa usar tantos como núcleos haya en la CPU.

‘--max-jobs=N’
‘-M N’
     Permite como máximo N trabajos de construcción en paralelo.  *Note
     ‘--max-jobs’: Invocación de guix-daemon, para detalles acerca de
     esta opción y la opción equivalente de ‘guix-daemon’.

‘--debug=NIVEL’
     Usa el nivel de detalle proporcionado en los mensajes procedentes
     del daemon de construcción.  NIVEL debe ser un entero entre 0 y 5;
     valores mayores indican una salida más detallada.  Establecer un
     nivel de 4 o superior puede ser útil en la depuración de problemas
     de configuración con el daemon de construcción.

   Tras las cortinas, ‘guix build’ es esencialmente una interfaz al
procedimiento ‘package-derivation’ del módulo ‘(guix packages)’, y al
procedimiento ‘build-derivations’ del módulo ‘(guix derivations)’.

   Además de las opciones proporcionadas explícitamente en la línea de
órdenes, ‘guix build’ y otras órdenes ‘guix’ que permiten la
construcción respetan el contenido de la variable de entorno
‘GUIX_BUILD_OPTIONS’.

 -- Variable de entorno: GUIX_BUILD_OPTIONS
     Las usuarias pueden definir esta variable para que contenga una
     lista de opciones de línea de órdenes que se usarán automáticamente
     por ‘guix build’ y otras órdenes ‘guix’ que puedan realizar
     construcciones, como en el ejemplo siguiente:

          $ export GUIX_BUILD_OPTIONS="--no-substitutes -c 2 -L /foo/bar"

     Estas opciones se analizan independientemente, y el resultado se
     añade a continuación de las opciones de línea de órdenes.


File: guix.es.info,  Node: Opciones de transformación de paquetes,  Next: Opciones de construcción adicionales,  Prev: Opciones comunes de construcción,  Up: Invocación de guix build

10.1.2 Opciones de transformación de paquetes
---------------------------------------------

Otro conjunto de opciones de línea de órdenes permitidas por ‘guix
build’ y también ‘guix package’ son las “opciones de transformación de
paquetes”.  Son opciones que hacen posible la definición de “variaciones
de paquetes”—por ejemplo, paquetes construidos con un código fuente
diferente.  Es una forma conveniente de crear paquetes personalizados al
vuelo sin tener que escribir las definiciones de las variaciones del
paquete (*note Definición de paquetes::).

   Las opciones de transformación del paquete se preservan con las
actualizaciones: ‘guix upgrade’ intenta aplicar las opciones de
transformación usadas inicialmente al crear el perfil para actualizar
los paquetes.

   Las opciones disponibles se enumeran a continuación.  La mayor parte
de las ordenes los aceptan, así como la opción ‘--help-transform’ que
enumera todas las opciones disponibles y una sinópsis (estas opciones no
se muestran en la salida de ‘--help’ por brevedad).

‘--tune[=CPU]’
     Use versions of the packages marked as “tunable” optimized for CPU.
     When CPU is ‘native’, or when it is omitted, tune for the CPU on
     which the ‘guix’ command is running.

     Valid CPU names are those recognized by the underlying compiler, by
     default the GNU Compiler Collection.  On x86_64 processors, this
     includes CPU names such as ‘nehalem’, ‘haswell’, and ‘skylake’
     (*note ‘-march’: (gcc)x86 Options.).

     As new generations of CPUs come out, they augment the standard
     instruction set architecture (ISA) with additional instructions, in
     particular instructions for single-instruction/multiple-data (SIMD)
     parallel processing.  For example, while Core2 and Skylake CPUs
     both implement the x86_64 ISA, only the latter supports AVX2 SIMD
     instructions.

     The primary gain one can expect from ‘--tune’ is for programs that
     can make use of those SIMD capabilities _and_ that do not already
     have a mechanism to select the right optimized code at run time.
     Packages that have the ‘tunable?’ property set are considered
     “tunable packages” by the ‘--tune’ option; a package definition
     with the property set looks like this:

          (package
            (name "hello-simd")
            ;; ...

            ;; This package may benefit from SIMD extensions so
            ;; mark it as "tunable".
            (properties '((tunable? . #t))))

     Other packages are not considered tunable.  This allows Guix to use
     generic binaries in the cases where tuning for a specific CPU is
     unlikely to provide any gain.

     Tuned packages are built with ‘-march=CPU’; under the hood, the
     ‘-march’ option is passed to the actual wrapper by a compiler
     wrapper.  Since the build machine may not be able to run code for
     the target CPU micro-architecture, the test suite is not run when
     building a tuned package.

     To reduce rebuilds to the minimum, tuned packages are _grafted_
     onto packages that depend on them (*note grafts: Actualizaciones de
     seguridad.).  Thus, using ‘--no-grafts’ cancels the effect of
     ‘--tune’.

     We call this technique “package multi-versioning”: several variants
     of tunable packages may be built, one for each CPU variant.  It is
     the coarse-grain counterpart of “function multi-versioning” as
     implemented by the GNU tool chain (*note (gcc)Function
     Multiversioning::).

‘--with-source=FUENTE’
‘--with-source=PAQUETE=FUENTE’
‘--with-source=PAQUETE@VERSIÓN=FUENTE’
     Usa FUENTE como la fuente de PAQUETE, y VERSIÓN como su número de
     versión.  FUENTE debe ser un nombre de archivo o una URL, como en
     ‘guix download’ (*note Invocación de guix download::).

     Cuando se omite PAQUETE, se toma el nombre de paquete especificado
     en la línea de ordenes que coincide con el nombre base de
     FUENTE—por ejemplo, si FUENTE fuese ‘/src/guile-2.0.10.tar.gz’, el
     paquete correspondiente sería ‘guile’.

     Del mismo modo, si se omite VERSIÓN, la cadena de versión se deduce
     de ĐUENTE; en el ejemplo previo sería ‘2.0.10’.

     Esta opción permite a las usuarias probar versiones del paquete
     distintas a las proporcionadas en la distribución.  El ejemplo
     siguiente descarga ‘ed-1.7.tar.gz’ de un espejo GNU y lo usa como
     la fuente para el paquete ‘ed’:

          guix build ed --with-source=mirror://gnu/ed/ed-1.4.tar.gz

     As a developer, ‘--with-source’ makes it easy to test release
     candidates, and even to test their impact on packages that depend
     on them:

          guix build elogind --with-source=.../shepherd-0.9.0rc1.tar.gz

     ... o la construcción desde una revisión en un entorno limpio:

          $ git clone git://git.sv.gnu.org/guix.git
          $ guix build guix --with-source=guix@1.0=./guix

‘--with-input=PAQUETE=REEMPLAZO’
     Substituye dependencias de PAQUETE por dependencias de REEMPLAZO.
     PAQUETE debe ser un nombre de paquete, y REEMPLAZO debe ser una
     especificación de paquete como ‘guile’ o ‘guile@1.8’.

     Por ejemplo, la orden siguiente construye Guix, pero substituye su
     dependencia de la versión estable actual de Guile con una
     dependencia en la versión antigua de Guile, ‘guile@2.0’:

          guix build --with-input=guile=guile@2.0 guix

     Esta sustitución se realiza de forma recursiva y en profundidad.
     Por lo que en este ejemplo, tanto ‘guix’ como su dependencia
     ‘guile-json’ (que también depende de ‘guile’) se reconstruyen
     contra ‘guile@2.0’.

     Se implementa usando el procedimiento Scheme
     ‘package-input-rewriting’ (*note ‘package-input-rewriting’:
     Definición de paquetes.).

‘--with-graft=PAQUETE=REEMPLAZO’
     Es similar a ‘--with-input’ pero con una diferencia importante: en
     vez de reconstruir la cadena de dependencias completa, REEMPLAZO se
     construye y se “injerta” en los binarios que inicialmente hacían
     referencia a PAQUETE.  *Note Actualizaciones de seguridad::, para
     más información sobre injertos.

     Por ejemplo, la orden siguiente injerta la versión 3.5.4 de GnuTLS
     en Wget y todas sus dependencias, substituyendo las referencias a
     la versión de GnuTLS que tienen actualmente:

          guix build --with-graft=gnutls=gnutls@3.5.4 wget

     Esta opción tiene la ventaja de ser mucho más rápida que la
     reconstrucción de todo.  Pero hay una trampa: funciona si y solo si
     PAQUETE y REEMPLAZO son estrictamente compatibles—por ejemplo, si
     proporcionan una biblioteca, la interfaz binaria de aplicación
     (ABI) de dichas bibliotecas debe ser compatible.  Si REEMPLAZO es
     incompatible de alguna manera con PAQUETE, el paquete resultante
     puede no ser usable.  ¡Úsela con precaución!

‘--with-debug-info=PAQUETE’
     Construye PAQUETE de modo que preserve su información de depuración
     y lo injerta en los paquetes que dependan de él.  Es útil si
     PAQUETE no proporciona ya información de depuración como una salida
     ‘debug’ (*note Instalación de archivos de depuración::).

     Por ejemplo, supongamos que está experimentando un fallo en
     Inkscape y querría ver qué pasa en GLib, una biblioteca con mucha
     profundidad en el grafo de dependencias de Inkscape.  GLib no tiene
     una salida ‘debug’, de modo que su depuración es difícil.
     Afortunadamente puede reconstruir GLib con información de
     depuración e incorporarla a Inkscape:

          guix install inkscape --with-debug-info=glib

     Únicamente GLib necesita una reconstrucción por lo que esto tarda
     un tiempo razonable.  *Note Instalación de archivos de depuración::
     para obtener más información.

          Nota: Esta opción funciona en su implementación interna
          proporcionando ‘#:strip-binaries? #f’ al sistema de
          construcción del paquete en cuestión (*note Sistemas de
          construcción::).  La mayor parte de sistemas de construcción
          implementan dicha opción, pero algunos no lo hacen.  En este
          caso caso se emite un error.

          De igual modo, si se construye un paquete C/C++ sin la opción
          ‘-g’ (lo que no es habitual que ocurra), la información de
          depuración seguirá sin estar disponible incluso cuando
          ‘#:strip-binaries?’ sea falso.

‘--with-c-toolchain=PAQUETE=CADENA’
     Esta opción cambia la compilación de PAQUETE y todo lo que dependa
     de él de modo que se constuya con CADENA en vez de la cadena de
     herramientas de construcción para C/C++ de GNU predeterminada.

     Considere este ejemplo:

          guix build octave-cli \
            --with-c-toolchain=fftw=gcc-toolchain@10 \
            --with-c-toolchain=fftwf=gcc-toolchain@10

     La orden anterior construye una variante de los paquetes ‘fftw’ y
     ‘fftwf’ usando la versión 10 de ‘gcc-toolchain’ en vez de la cadena
     de herramientas de construcción predeterminada, y construye una
     variante de la interfaz de línea de órdenes GNU Octave que hace uso
     de ellos.  El propio paquete de GNU Octave también se construye con
     ‘gcc-toolchain@10’.

     Este otro ejemplo construye la biblioteca Hardware Locality
     (‘hwloc’) y los paquetes que dependan de ella hasta
     ‘intel-mpi-benchmarks’ con el compilador de C Clang:

          guix build --with-c-toolchain=hwloc=clang-toolchain \
                     intel-mpi-benchmarks

          Nota: There can be application binary interface (ABI)
          incompatibilities among tool chains.  This is particularly
          true of the C++ standard library and run-time support
          libraries such as that of OpenMP.  By rebuilding all
          dependents with the same tool chain, ‘--with-c-toolchain’
          minimizes the risks of incompatibility but cannot entirely
          eliminate them.  Choose PACKAGE wisely.

‘--with-git-url=PAQUETE=URL’
     Construye PAQUETE desde la última revisión de la rama ‘master’ del
     repositorio Git en URL.  Los submódulos del repositorio Git se
     obtienen de forma recursiva.

     Por ejemplo, la siguiente orden construye la biblioteca NumPy de
     Python contra la última revisión de la rama master de Python en sí:

          guix build python-numpy \
            --with-git-url=python=https://github.com/python/cpython

     Esta opción también puede combinarse con ‘--with-branch’ o
     ‘--with-commit’ (véase más adelante).

     Obviamente, ya que se usa la última revisión de la rama
     proporcionada, el resultado de dicha orden varia con el tiempo.  No
     obstante es una forma conveniente de reconstruir una pila completa
     de software contra las últimas revisiones de uno o varios paquetes.
     Esto es particularmente útil en el contexto de integración continua
     (CI).

     Los directorios de trabajo se conservan en caché en
     ‘~/.cache/guix/checkouts’ para agilizar accesos consecutivos al
     mismo repositorio.  Puede desear limpiarla de vez en cuando para
     ahorrar espacio en el disco.

‘--with-branch=PAQUETE=RAMA’
     Construye PAQUETE desde la última revisión de RAMA.  Si el campo
     ‘source’ de PAQUETE es un origen con el método ‘git-fetch’ (*note
     Referencia de origin::) o un objeto ‘git-checkout’, la URL del
     repositorio se toma de dicho campo ‘source’.  En otro caso, se debe
     especificar la URL del repositorio Git mediante el uso de
     ‘--with-git-url’.

     Por ejemplo, la siguiente orden construye ‘guile-sqlite3’ desde la
     última revisión de su rama ‘master’ y, una vez hecho, construye
     ‘guix’ (que depende de él) y ‘cuirass’ (que depende de ‘guix’) en
     base a esta construcción específica de ‘guile-sqlite3’:

          guix build --with-branch=guile-sqlite3=master cuirass

‘--with-commit=PAQUETE=REVISIÓN’
     This is similar to ‘--with-branch’, except that it builds from
     COMMIT rather than the tip of a branch.  COMMIT must be a valid Git
     commit SHA1 identifier, a tag, or a ‘git describe’ style identifier
     such as ‘1.0-3-gabc123’.

‘--with-patch=PACKAGE=FILE’
     Add FILE to the list of patches applied to PACKAGE, where PACKAGE
     is a spec such as ‘python@3.8’ or ‘glibc’.  FILE must contain a
     patch; it is applied with the flags specified in the ‘origin’ of
     PACKAGE (*note Referencia de origin::), which by default includes
     ‘-p1’ (*note (diffutils)patch Directories::).

     As an example, the command below rebuilds Coreutils with the GNU C
     Library (glibc) patched with the given patch:

          guix build coreutils --with-patch=glibc=./glibc-frob.patch

     In this example, glibc itself as well as everything that leads to
     Coreutils in the dependency graph is rebuilt.

‘--with-latest=PACKAGE’
     So you like living on the bleeding edge?  This option is for you!
     It replaces occurrences of PACKAGE in the dependency graph with its
     latest upstream version, as reported by ‘guix refresh’ (*note
     Invocación de guix refresh::).

     It does so by determining the latest upstream release of PACKAGE
     (if possible), downloading it, and authenticating it _if_ it comes
     with an OpenPGP signature.

     As an example, the command below builds Guix against the latest
     version of Guile-JSON:

          guix build guix --with-latest=guile-json

     There are limitations.  First, in cases where the tool cannot or
     does not know how to authenticate source code, you are at risk of
     running malicious code; a warning is emitted in this case.  Second,
     this option simply changes the source used in the existing package
     definitions, which is not always sufficient: there might be
     additional dependencies that need to be added, patches to apply,
     and more generally the quality assurance work that Guix developers
     normally do will be missing.

     You’ve been warned!  In all the other cases, it’s a snappy way to
     stay on top.  We encourage you to submit patches updating the
     actual package definitions once you have successfully tested an
     upgrade (*note Contribuir::).

‘--without-tests=PAQUETE’
     Construye PAQUETE sin ejecutar su batería de pruebas.  Puede ser
     útil en situaciones en las que quiera omitir una larga batería de
     pruebas de un paquete intermedio, o si la batería de pruebas no
     falla de manera determinista.  Debe usarse con cuidado, puesto que
     la ejecución de la batería de pruebas es una buena forma de
     asegurarse de que el paquete funciona como se espera.

     La desactivación de las pruebas conduce a diferentes elementos en
     el almacén.  Por tanto, cuando use esta opción, cualquier objeto
     que dependa de PAQUETE debe ser reconstruido, como en este ejemplo:

          guix install --without-tests=python python-notebook

     La orden anterior instala ‘python-notebook’ sobre un paquete
     ‘python’ construido sin ejecutar su batería de pruebas.  Para
     hacerlo, también reconstruye todos los paquetes que dependen de
     ‘python’, incluyendo el propio ‘pyhton-notebook’.

     De manera interna, ‘--without-tests’ depende del cambio de la
     opción ‘#:tests?’ de la fase ‘check’ del paquete (*note Sistemas de
     construcción::).  Tenga en cuenta que algunos paquetes usan una
     fase ‘check’ personalizada que no respeta el valor de configuración
     ‘#:tests? #f’.  Por tanto, ‘--without-tests’ no tiene ningún efecto
     en dichos paquetes.

   ¿Se pregunta cómo conseguir el mismo efecto usando código Scheme, por
ejemplo en su manifiesto, o cómo escribir su propia transformación de
paquetes?  *Note Definición de variantes de paquetes:: para obtener una
descripción de la interfaz programática disponible.


File: guix.es.info,  Node: Opciones de construcción adicionales,  Next: Depuración de fallos de construcción,  Prev: Opciones de transformación de paquetes,  Up: Invocación de guix build

10.1.3 Opciones de construcción adicionales
-------------------------------------------

Las opciones de línea de ordenes presentadas a continuación son
específicas de ‘guix build’.

‘--quiet’
‘-q’
     Construye silenciosamente, sin mostrar el registro de construcción;
     es equivalente a ‘--verbosity=0’.  Al finalizar, el registro de
     construcción se mantiene en ‘/var’ (o similar) y puede recuperarse
     siempre mediante el uso de la opción ‘--log-file’.

‘--file=ARCHIVO’
‘-f ARCHIVO’
     Construye el paquete, derivación u otro objeto tipo-archivo al que
     evalúa el código en ARCHIVO (*note objetos “tipo-archivo”:
     Expresiones-G.).

     Como un ejemplo, ARCHIVO puede contener una definición como esta
     (*note Definición de paquetes::):

          (use-modules (guix)
                       (guix build-system gnu)
                       (guix licenses))

          (package
            (name "hello")
            (version "2.10")
            (source (origin
                      (method url-fetch)
                      (uri (string-append "mirror://gnu/hello/hello-" version
                                          ".tar.gz"))
                      (sha256
                       (base32
                        "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i"))))
            (build-system gnu-build-system)
            (synopsis "Hello, GNU world: An example GNU package")
            (description "Guess what GNU Hello prints!")
            (home-page "http://www.gnu.org/software/hello/")
            (license gpl3+))

     El ARCHIVO también puede contener una representación en JSON de una
     o más definiciones de paquete.  Ejecutar ‘guix build -f’ en
     ‘hello.json’ con el siguiente contenido resultaría en la
     construcción de los paquetes ‘myhello’ y ‘greeter’:

          [
            {
              "name": "myhello",
              "version": "2.10",
              "source": "mirror://gnu/hello/hello-2.10.tar.gz",
              "build-system": "gnu",
              "arguments": {
                "tests?": false
              }
              "home-page": "https://www.gnu.org/software/hello/",
              "synopsis": "Hello, GNU world: An example GNU package",
              "description": "GNU Hello prints a greeting.",
              "license": "GPL-3.0+",
              "native-inputs": ["gettext"]
            },
            {
              "name": "greeter",
              "version": "1.0",
              "source": "https://example.com/greeter-1.0.tar.gz",
              "build-system": "gnu",
              "arguments": {
                "test-target": "foo",
                "parallel-build?": false,
              },
              "home-page": "https://example.com/",
              "synopsis": "Greeter using GNU Hello",
              "description": "This is a wrapper around GNU Hello.",
              "license": "GPL-3.0+",
              "inputs": ["myhello", "hello"]
            }
          ]

‘--manifest=MANIFIESTO’
‘-m MANIFIESTO’
     Construye todos los paquetes listados en el MANIFIESTO
     proporcionado (*note ‘--manifest’: profile-manifest.).

‘--expression=EXPR’
‘-e EXPR’
     Construye el paquete o derivación a la que evalúa EXPR.

     Por ejemplo, EXPR puede ser ‘(@ (gnu packages guile) guile-1.8)’,
     que designa sin ambigüedad a esta variante específica de la versión
     1.8 de Guile.

     De manera alternativa, EXPR puede ser una expresión-G, en cuyo caso
     se usa como un programa de construcción pasado a ‘gexp->derivation’
     (*note Expresiones-G::).

     Por último, EXPR puede hacer referencia a un procedimiento mónadico
     sin parámetros (*note La mónada del almacén::).  El procedimiento
     debe devolver una derivación como un valor monádico, el cual
     después se pasa a través de ‘run-with-store’.

‘--source’
‘-S’
     Construye las derivaciones de las fuentes de los paquetes, en vez
     de los paquetes mismos.

     Por ejemplo, ‘guix build -S gcc’ devuelve algo como
     ‘/gnu/store/...-gcc-4.7.2.tar.bz2’, el cual es el archivador tar de
     fuentes de GCC.

     El archivador tar devuelto es el resultado de aplicar cualquier
     parche y fragmento de código en el origen (campo ‘origin’) del
     paquete (*note Definición de paquetes::).

     As with other derivations, the result of building a source
     derivation can be verified using the ‘--check’ option (*note
     build-check::).  This is useful to validate that a (potentially
     already built or substituted, thus cached) package source matches
     against its declared hash.

     Tenga en cuenta que ‘guix build -S’ compila las fuentes únicamente
     de los paquetes especificados.  Esto no incluye las dependencias
     enlazadas estáticamente y por sí mismas son insuficientes para
     reproducir los paquetes.

‘--sources’
     Obtiene y devuelve las fuentes de PAQUETE-O-DERIVACIÓN y todas sus
     dependencias, de manera recursiva.  Esto es útil para obtener una
     copia local de todo el código fuente necesario para construir los
     PAQUETES, le permite construirlos llegado el momento sin acceso a
     la red.  Es una extensión de la opción ‘--source’ y puede aceptar
     uno de los siguientes valores opcionales como parámetro:

     ‘package’
          Este valor hace que la opción ‘--sources’ se comporte de la
          misma manera que la opción ‘--source’.

     ‘all’
          Construye las derivaciones de las fuentes de todos los
          paquetes, incluyendo cualquier fuente que pueda enumerarse
          como entrada (campo ‘inputs’).  Este es el valor
          predeterminado.

               $ guix build --sources tzdata
               The following derivations will be built:
                  /gnu/store/...-tzdata2015b.tar.gz.drv
                  /gnu/store/...-tzcode2015b.tar.gz.drv

     ‘transitive’
          Construye las derivaciones de fuentes de todos los paquetes,
          así como todas las entradas transitivas de los paquetes.  Esto
          puede usarse, por ejemplo, para obtener las fuentes de
          paquetes para una construcción posterior sin conexión a la
          red.

               $ guix build --sources=transitive tzdata
               The following derivations will be built:
                  /gnu/store/...-tzcode2015b.tar.gz.drv
                  /gnu/store/...-findutils-4.4.2.tar.xz.drv
                  /gnu/store/...-grep-2.21.tar.xz.drv
                  /gnu/store/...-coreutils-8.23.tar.xz.drv
                  /gnu/store/...-make-4.1.tar.xz.drv
                  /gnu/store/...-bash-4.3.tar.xz.drv
               ...

‘--system=SISTEMA’
‘-s SISTEMA’
     Intenta la construcción para SISTEMA—por ejemplo, ‘i686-linux’—en
     vez del tipo de sistema de la máquina de construcción.  La orden
     ‘guix build’ le permite repetir esta opción varias veces, en cuyo
     caso construye para todos los sistemas especificados; otras ordenes
     ignoran opciones ‘-s’ extrañas.

          Nota: La opción ‘--system’ es para compilación _nativa_ y no
          debe confundirse con la compilación cruzada.  Véase ‘--target’
          más adelante para información sobre compilación cruzada.

     Un ejemplo de uso de esta opción es en sistemas basados en Linux,
     que pueden emular diferentes personalidades.  Por ejemplo,
     proporcionar la opción ‘--system=i686-linux’ en un sistema
     ‘x86_64-linux’, o la opción ‘--system=armhf-linux’ en un sistema
     ‘aarch64-linux’, le permite construir paquetes en un entorno de
     32-bits completo.

          Nota: La construcción para un sistema ‘armhf-linux’ está
          disponible de manera incondicional en máquinas
          ‘aarch64-linux’, aunque determinadas familias de procesadores
          aarch64 no lo permitan, notablemente el ThunderX.

     De manera similar, cuando la emulación transparente con QEMU y
     ‘binfmt_misc’ está activada (*note ‘qemu-binfmt-service-type’:
     Servicios de virtualización.), puede construir para cualquier
     sistema para el que un manejador QEMU de ‘binfmt_misc’ esté
     instalado.

     Las construcciones para un sistema distinto al de la máquina que
     usa se pueden delegar también a una máquina remota de la
     arquitectura correcta.  *Note Configuración de delegación del
     daemon::, para más información sobre delegación.

‘--target=TRIPLETA’
     Compilación cruzada para la TRIPLETA, que debe ser una tripleta GNU
     válida, cómo ‘"aarch64-linux-gnu"’ (*note GNU configuration
     triplets: (autoconf)Specifying Target triplets.).

‘--list-systems’
     List all the supported systems, that can be passed as an argument
     to ‘--system’.

‘--list-targets’
     List all the supported targets, that can be passed as an argument
     to ‘--target’.

‘--check’
     Reconstruye PAQUETE-O-DERIVACIÓN, que ya está disponible en el
     almacén, y emite un error si los resultados de la construcción no
     son idénticos bit-a-bit.

     Este mecanismo le permite comprobar si sustituciones previamente
     instaladas son genuinas (*note Sustituciones::), o si el resultado
     de la construcción de un paquete es determinista.  *Note Invocación
     de guix challenge::, para más información de referencia y
     herramientas.

     Cuando se usa conjuntamente con ‘--keep-failed’, la salida que
     difiere se mantiene en el almacén, bajo ‘/gnu/store/...-check’.
     Esto hace fácil buscar diferencias entre los dos resultados.

‘--repair’
     Intenta reparar los elementos del almacén especificados, si están
     corruptos, volviendo a descargarlos o mediante su reconstrucción.

     Esta operación no es atómica y por lo tanto está restringida a
     ‘root’.

‘--derivations’
‘-d’
     Devuelve las rutas de derivación, no las rutas de salida, de los
     paquetes proporcionados.

‘--root=ARCHIVO’
‘-r ARCHIVO’
     Hace que ARCHIVO sea un enlace simbólico al resultado, y lo
     registra como una raíz del recolector de basura.

     Consecuentemente, los resultados de esta invocación de ‘guix build’
     se protegen de la recolección de basura hasta que ARCHIVO se
     elimine.  Cuando se omite esa opción, los resultados son candidatos
     a la recolección de basura en cuanto la construcción se haya
     completado.  *Note Invocación de guix gc::, para más sobre las
     raíces del recolector de basura.

‘--log-file’
     Devuelve los nombres de archivos o URL de los log de construcción
     para el PAQUETE-O-DERIVACIÓN proporcionado, o emite un error si no
     se encuentran los log de construcción.

     Esto funciona independientemente de cómo se especificasen los
     paquetes o derivaciones.  Por ejemplo, las siguientes invocaciones
     son equivalentes:

          guix build --log-file $(guix build -d guile)
          guix build --log-file $(guix build guile)
          guix build --log-file guile
          guix build --log-file -e '(@ (gnu packages guile) guile-2.0)'

     Si no está disponible un registro local, y a menos que se
     proporcione ‘--no-substitutes’, la orden busca el registro
     correspondiente en uno de los servidores de sustituciones (como se
     especificaron con ‘--substitute-urls’).

     So for instance, imagine you want to see the build log of GDB on
     ‘aarch64’, but you are actually on an ‘x86_64’ machine:

          $ guix build --log-file gdb -s aarch64-linux
          https://ci.guix.gnu.org/log/...-gdb-7.10

     ¡Puede acceder libremente a una biblioteca inmensa de log de
     construcción!


File: guix.es.info,  Node: Depuración de fallos de construcción,  Prev: Opciones de construcción adicionales,  Up: Invocación de guix build

10.1.4 Depuración de fallos de construcción
-------------------------------------------

Cuando esté definiendo un paquete nuevo (*note Definición de
paquetes::), probablemente se encuentre que dedicando algún tiempo a
depurar y afinar la construcción hasta obtener un resultado
satisfactorio.  Para hacerlo, tiene que lanzar manualmente las órdenes
de construcción en un entorno tan similar como sea posible al que el
daemon de construcción usa.

   To that end, the first thing to do is to use the ‘--keep-failed’ or
‘-K’ option of ‘guix build’, which will keep the failed build tree in
‘/tmp’ or whatever directory you specified as ‘TMPDIR’ (*note
‘--keep-failed’: Opciones comunes de construcción.).

   De ahí en adelante, puede usar ‘cd’ para ir al árbol de la
construcción fallida y cargar el archivo ‘environment-variables’, que
contiene todas las definiciones de variables de entorno que existían
cuando la construcción falló.  Digamos que está depurando un fallo en la
construcción del paquete ‘foo’; una sesión típica sería así:

     $ guix build foo -K
     ... build fails
     $ cd /tmp/guix-build-foo.drv-0
     $ source ./environment-variables
     $ cd foo-1.2

   Ahora puede invocar órdenes (casi) como si fuese el daemon y
encontrar los errores en su proceso de construcción.

   A veces ocurre que, por ejemplo, las pruebas de un paquete pasan
cuando las ejecuta manualmente pero fallan cuando el daemon las ejecuta.
Esto puede suceder debido a que el daemon construye dentro de
contenedores donde, al contrario que en nuestro entorno previo, el
acceso a la red no está disponible, ‘/bin/sh’ no existe, etc.  (*note
Configuración del entorno de construcción::).

   En esos casos, puede tener que inspeccionar el proceso de
construcción desde un contenedor similar al creado por el daemon de
construcción:

     $ guix build -K foo
     ...
     $ cd /tmp/guix-build-foo.drv-0
     $ guix shell --no-grafts -C -D foo strace gdb
     [env]# source ./environment-variables
     [env]# cd foo-1.2

   Here, ‘guix shell -C’ creates a container and spawns a new shell in
it (*note Invoking guix shell::).  The ‘strace gdb’ part adds the
‘strace’ and ‘gdb’ commands to the container, which you may find handy
while debugging.  The ‘--no-grafts’ option makes sure we get the exact
same environment, with ungrafted packages (*note Actualizaciones de
seguridad::, for more info on grafts).

   Para acercarnos más al contenedor usado por el daemon de
construcción, podemos eliminar ‘/bin/sh’:

     [env]# rm /bin/sh

   (Don’t worry, this is harmless: this is all happening in the
throw-away container created by ‘guix shell’.)

   La orden ‘strace’ probablemente no esté en la ruta de búsqueda, pero
podemos ejecutar:

     [env]# $GUIX_ENVIRONMENT/bin/strace -f -o log make check

   De este modo, no solo habrá reproducido las variables de entorno que
usa el daemon, también estará ejecutando el proceso de construcción en
un contenedor similar al usado por el daemon.


File: guix.es.info,  Node: Invocación de guix edit,  Next: Invocación de guix download,  Prev: Invocación de guix build,  Up: Utilidades

10.2 Invocación de ‘guix edit’
==============================

¡Tantos paquetes, tantos archivos de fuentes!  La orden ‘guix edit’
facilita la vida de las usuarias y empaquetadoras apuntando su editor al
archivo de fuentes que contiene la definición de los paquetes
especificados.  Por ejemplo:

     guix edit gcc@4.9 vim

ejecuta el programa especificado en la variable de entorno ‘VISUAL’ o en
‘EDITOR’ para ver la receta de GCC 4.9.3 y la de Vim.

   Si está usando una copia de trabajo de Git de Guix (*note
Construcción desde Git::), o ha creado sus propios paquetes en
‘GUIX_PACKAGE_PATH’ (*note Módulos de paquetes::), será capaz de editar
las recetas de los paquetes.  En otros casos, podrá examinar las recetas
en modo de lectura únicamente para paquetes actualmente en el almacén.

   En vez de ‘GUIX_PACKAGE_PATH’, la opción de línea de ordenes
‘--load-path=DIRECTORIO’ (o en versión corta ‘-L DIRECTORIO’) le permite
añadir DIRECTORIO al inicio de la ruta de búsqueda de módulos de paquete
y hacer visibles sus propios paquetes.


File: guix.es.info,  Node: Invocación de guix download,  Next: Invocación de guix hash,  Prev: Invocación de guix edit,  Up: Utilidades

10.3 Invocación de ‘guix download’
==================================

Durante la escritura de una definición de paquete, las desarrolladoras
típicamente tienen que descargar un archivador tar de fuentes, calcular
su hash SHA256 y escribir ese hash en la definición del paquete (*note
Definición de paquetes::).  La herramienta ‘guix download’ ayuda con
esta tarea: descarga un archivo de la URI proporcionada, lo añade al
almacén e imprime tanto su nombre de archivo en el almacén como su hash
SHA256.

   El hecho de que el archivo descargado se añada al almacén ahorra
ancho de banda: cuando el desarrollador intenta construir el paquete
recién definido con ‘guix build’, el archivador de fuentes no tiene que
descargarse de nuevo porque ya está en el almacén.  También es una forma
conveniente de conservar archivos temporalmente, que pueden ser borrados
en un momento dado (*note Invocación de guix gc::).

   La orden ‘guix download’ acepta las mismas URI que las usadas en las
definiciones de paquetes.  En particular, permite URI ‘mirror://’.  Las
URI ‘https’ (HTTP sobre TLS) se aceptan _cuando_ el enlace Guile con
GnuTLS está disponible en el entorno de la usuaria; cuando no está
disponible se emite un error.  *Note how to install the GnuTLS bindings
for Guile: (gnutls-guile)Guile Preparations, para más información.

   ‘guix download’ verifica los certificados del servidor HTTPS cargando
las autoridades X.509 del directorio al que apunta la variable de
entorno ‘SSL_CERT_DIR’ (*note Certificados X.509::), a menos que se use
‘--no-check-certificate’.

   Las siguientes opciones están disponibles:

‘--hash=ALGORITMO’
‘-H ALGORITMO’
     Calcula el resultado del hash usando el ALGORITMO proporcionado.
     *Note Invocación de guix hash::, para más información.

‘--format=FMT’
‘-f FMT’
     Escribe el hash en el formato especificado por FMT.  Para más
     información sobre los valores aceptados en FMT, *note Invocación de
     guix hash::.

‘--no-check-certificate’
     No valida los certificados X.509 de los servidores HTTPS.

     Cuando se usa esta opción, no tiene _absolutamente ninguna
     garantía_ de que está comunicando con el servidor responsable de la
     URL auténtico, lo que le hace vulnerables a ataques de
     interceptación (“man-in-the-middle”).

‘--output=ARCHIVO’
‘-o ARCHIVO’
     Almacena el archivo descargado en ARCHIVO en vez de añadirlo al
     almacén.


File: guix.es.info,  Node: Invocación de guix hash,  Next: Invocación de guix import,  Prev: Invocación de guix download,  Up: Utilidades

10.4 Invocación de ‘guix hash’
==============================

The ‘guix hash’ command computes the hash of a file.  It is primarily a
convenience tool for anyone contributing to the distribution: it
computes the cryptographic hash of one or more files, which can be used
in the definition of a package (*note Definición de paquetes::).

   La sintaxis general es:

     guix hash OPTION FILE ...

   Cuando ARCHIVO es ‘-’ (un guión), ‘guix hash’ calcula el hash de los
datos leídos por la entrada estándar.  ‘guix hash’ tiene las siguientes
opciones:

‘--hash=ALGORITMO’
‘-H ALGORITMO’
     Calcula un hash usando el ALGORITMO especificado, ‘sha256’ de
     manera predeterminada.

     ALGORITHM must be the name of a cryptographic hash algorithm
     supported by Libgcrypt via Guile-Gcrypt—e.g., ‘sha512’ or
     ‘sha3-256’ (*note (guile-gcrypt)Hash Functions::).

‘--format=FMT’
‘-f FMT’
     Escribe el hash en el formato especificado por FMT.

     Los formatos disponibles son: ‘base64’, ‘nix-base32’, ‘base32’,
     ‘base16’ (se puede usar también ‘hex’ y ‘hexadecimal’).

     Si no se especifica la opción ‘--format’, ‘guix hash’ mostrará el
     hash en ‘nix-base32’.  Esta representación es la usada en las
     definiciones de paquetes.

‘--recursive’
‘-r’
     The ‘--recursive’ option is deprecated in favor of
     ‘--serializer=nar’ (see below); ‘-r’ remains accepted as a
     convenient shorthand.

‘--serializer=TYPE’
‘-S TYPE’
     Compute the hash on FILE using TYPE serialization.

     TYPE may be one of the following:

     ‘none’
          This is the default: it computes the hash of a file’s
          contents.

     ‘nar’
          Compute the hash of a “normalized archive” (or “nar”)
          containing FILE, including its children if it is a directory.
          Some of the metadata of FILE is part of the archive; for
          instance, when FILE is a regular file, the hash is different
          depending on whether FILE is executable or not.  Metadata such
          as time stamps have no impact on the hash (*note Invocación de
          guix archive::, for more info on the nar format).

     ‘git’
          Compute the hash of the file or directory as a Git “tree”,
          following the same method as the Git version control system.

‘--exclude-vcs’
‘-x’
     Cuando se combina con ‘--recursive’, excluye los directorios del
     sistema de control de versiones (‘.bzr’, ‘.git’, ‘.hg’, etc.).

     Como un ejemplo, así es como calcularía el hash de una copia de
     trabajo Git, lo cual es útil cuando se usa el método ‘git-fetch’
     (*note Referencia de origin::):

          $ git clone http://example.org/foo.git
          $ cd foo
          $ guix hash -x --serializer=nar .


File: guix.es.info,  Node: Invocación de guix import,  Next: Invocación de guix refresh,  Prev: Invocación de guix hash,  Up: Utilidades

10.5 Invocación de ‘guix import’
================================

La orden ‘guix import’ es útil para quienes desean añadir un paquete a
la distribución con el menor trabajo posible—una demanda legítima.  La
orden conoce algunos repositorios de los que puede “importar” metadatos
de paquetes.  El resultado es una definición de paquete, o una plantilla
de ella, en el formato que conocemos (*note Definición de paquetes::).

   La sintaxis general es:

     guix import IMPORTADOR OPCIONES...

   IMPORTADOR especifica la fuente de la que se importan los metadatos
del paquete, OPCIONES especifica un identificador de paquete y otras
opciones específicas del IMPORTADOR.

   Algunos de los importadores dependen de poder ejecutar la orden
‘gpgv’.  Para ello, GnuPG debe estar instalado y en ‘$PATH’; ejecute
‘guix install gnupg’ si es necesario.

   Actualmente los “importadores” disponibles son:

‘gnu’
     Importa los metadatos del paquete GNU seleccionado.  Proporciona
     una plantilla para la última versión de dicho paquete GNU,
     incluyendo el hash de su archivador tar de fuentes, y su sinopsis y
     descripción canónica.

     Información adicional como las dependencias del paquete y su
     licencia deben ser deducidas manualmente.

     Por ejemplo, la siguiente orden devuelve una definición de paquete
     para GNU Hello.

          guix import gnu hello

     Las opciones específicas de línea de ordenes son:

     ‘--key-download=POLÍTICA’
          Como en ‘guix refresh’, especifica la política de tratamiento
          de las claves OpenPGP no encontradas cuando se verifica la
          firma del paquete.  *Note ‘--key-download’: Invocación de guix
          refresh.

‘pypi’
     Importa metadatos desde el índice de paquetes Python (PyPI)
     (https://pypi.python.org/).  La información se toma de la
     descripción con formato JSON disponible en ‘pypi.python.org’ y
     habitualmente incluye toda la información relevante, incluyendo las
     dependencias del paquete.  Para una máxima eficiencia, se
     recomienda la instalación de la utilidad ‘unzip’, de manera que el
     importador pueda extraer los archivos wheel de Python y obtener
     datos de ellos.

     The command below imports metadata for the latest version of the
     ‘itsdangerous’ Python package:

          guix import pypi itsdangerous

     You can also ask for a specific version:

          guix import pypi itsdangerous@1.1.0

     ‘--recursive’
     ‘-r’
          Recorre el grafo de dependencias del paquete original
          proporcionado recursivamente y genera expresiones de paquete
          para todos aquellos paquetes que no estén todavía en Guix.

‘gem’
     Importa metadatos desde RubyGems (https://rubygems.org/).  La
     información se extrae de la descripción en formato JSON disponible
     en ‘rubygems.org’ e incluye la información más relevante,
     incluyendo las dependencias en tiempo de ejecución.  Hay algunos
     puntos a tener en cuenta, no obstante.  Los metadatos no distinguen
     entre sinopsis y descripción, por lo que se usa la misma cadena
     para ambos campos.  Adicionalmente, los detalles de las
     dependencias no-Ruby necesarias para construir extensiones nativas
     no está disponible y se deja como ejercicio a la empaquetadora.

     La siguiente orden importa los meta-datos para el paquete de Ruby
     ‘rails’:

          guix import gem rails

     You can also ask for a specific version:

          guix import gem rails@7.0.4

     ‘--recursive’
     ‘-r’
          Recorre el grafo de dependencias del paquete original
          proporcionado recursivamente y genera expresiones de paquete
          para todos aquellos paquetes que no estén todavía en Guix.

‘minetest’
     Import metadata from ContentDB (https://content.minetest.net).
     Information is taken from the JSON-formatted metadata provided
     through ContentDB’s API (https://content.minetest.net/help/api/)
     and includes most relevant information, including dependencies.
     There are some caveats, however.  The license information is often
     incomplete.  The commit hash is sometimes missing.  The
     descriptions are in the Markdown format, but Guix uses Texinfo
     instead.  Texture packs and subgames are unsupported.

     The command below imports metadata for the Mesecons mod by Jeija:

          guix import minetest Jeija/mesecons

     The author name can also be left out:

          guix import minetest mesecons

     ‘--recursive’
     ‘-r’
          Recorre el grafo de dependencias del paquete original
          proporcionado recursivamente y genera expresiones de paquete
          para todos aquellos paquetes que no estén todavía en Guix.

‘cpan’
     Importa metadatos desde MetaCPAN (https://www.metacpan.org/).  La
     información se extrae de la descripción en formato JSON disponible
     a través del API de MetaCPAN (https://fastapi.metacpan.org/) e
     incluye la información más relevante, como las dependencias de
     otros módulos.  La información de la licencia debe ser comprobada
     atentamente.  Si Perl está disponible en el almacén, se usará la
     utilidad ‘corelist’ para borrar los módulos básicos de la lista de
     dependencias.

     La siguiente orden importa los metadatos del módulo Perl
     Acme::Boolean:

          guix import cpan Acme::Boolean

‘cran’
     Importa metadatos desde CRAN (https://cran.r-project.org/), el
     repositorio central para el entorno estadístico y gráfico GNU R
     (https://r-project.org).

     La información se extrae del archivo ‘DESCRIPTION’ del paquete.

     La siguiente orden importa los metadatos del paquete de R Cairo:

          guix import cran Cairo

     You can also ask for a specific version:

          guix import cran rasterVis@0.50.3

     Cuando se añade ‘--recursive’, el importador recorrerá el grafo de
     dependencias del paquete original proporcionado recursivamente y
     generará expresiones de paquetes para todos aquellos que no estén
     todavía en Guix.

     When ‘--style=specification’ is added, the importer will generate
     package definitions whose inputs are package specifications instead
     of references to package variables.  This is useful when generated
     package definitions are to be appended to existing user modules, as
     the list of used package modules need not be changed.  The default
     is ‘--style=variable’.

     Cuando se usa ‘--archive=bioconductor’, los metadatos se importan
     de Bioconductor (https://www.bioconductor.org), un repositorio de
     paquetes R para el análisis y comprensión de datos genéticos de
     alto caudal en bioinformática.

     La información se extrae del archivo ‘DESCRIPTION’ contenido en el
     archivo del paquete.

     La siguiente orden importa los metadatos del paquete de R
     GenomicRanges:

          guix import cran --archive=bioconductor GenomicRanges

     Por último, también puede importar paquetes de R que no se hayan
     publicado todavía en CRAN o en Bioconductor siempre que estén en un
     repositorio git.  Use ‘--archive=git’ seguido de la URL del
     repositorio git:

          guix import cran --archive=git https://github.com/immunogenomics/harmony

‘texlive’
     Import TeX package information from the TeX Live package database
     for TeX packages that are part of the TeX Live distribution
     (https://www.tug.org/texlive/).

     Information about the package is obtained from the TeX Live package
     database, a plain text file that is included in the ‘texlive-bin’
     package.  The source code is downloaded from possibly multiple
     locations in the SVN repository of the Tex Live project.

     La siguiente orden importa los metadatos del paquete de TeX
     ‘fontspec’:

          guix import texlive fontspec

‘json’
     Importa metadatos de paquetes desde un archivo JSON local.
     Considere el siguiente ejemplo de definición de paquete en formato
     JSON:

          {
            "name": "hello",
            "version": "2.10",
            "source": "mirror://gnu/hello/hello-2.10.tar.gz",
            "build-system": "gnu",
            "home-page": "https://www.gnu.org/software/hello/",
            "synopsis": "Hello, GNU world: An example GNU package",
            "description": "GNU Hello prints a greeting.",
            "license": "GPL-3.0+",
            "native-inputs": ["gettext"]
          }

     Los nombres de los campos son los mismos que para el registro
     ‘<package>’ (*Note Definición de paquetes::).  Las referencias a
     otros paquetes se proporcionan como listas JSON de cadenas de
     especificación de paquete entrecomilladas como ‘guile’ o
     ‘guile@2.0’.

     El importador también permite una definición de fuentes más
     explícita usando los campos comunes de los registros ‘<origin>’:

          {
            ...
            "source": {
              "method": "url-fetch",
              "uri": "mirror://gnu/hello/hello-2.10.tar.gz",
              "sha256": {
                "base32": "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i"
              }
            }
            ...
          }

     La siguiente orden importa los metadatos desde el archivo JSON
     ‘hello.json’ y devuelve una expresión de “package”:

          guix import json hello.json

‘hackage’
     Importa metadatos desde el archivo central de paquetes de la
     comunidad Haskell Hackage (https://hackage.haskell.org/).  La
     información se obtiene de archivos Cabal e incluye toda la
     información relevante, incluyendo las dependencias del paquete.

     Las opciones específicas de línea de ordenes son:

     ‘--stdin’
     ‘-s’
          Lee un archivo Cabal por la entrada estándar.
     ‘--no-test-dependencies’
     ‘-t’
          No incluye las dependencias necesarias únicamente para las
          baterías de pruebas.
     ‘--cabal-environment=ALIST’
     ‘-e ALIST’
          ALIST es una lista asociativa Scheme que define el entorno en
          el que los condicionales Cabal se evalúan.  Los valores
          aceptados son: ‘os’, ‘arch’, ‘impl’ y una cadena que
          representa el nombre de la condición.  El valor asociado a la
          condición tiene que ser o bien el símbolo ‘true’ o bien
          ‘false’.  Los valores predeterminados asociados a las claves
          ‘os’, ‘arch’ y ‘impl’ son ‘linux’, ‘x86_64’ y ‘ghc’,
          respectivamente.
     ‘--recursive’
     ‘-r’
          Recorre el grafo de dependencias del paquete original
          proporcionado recursivamente y genera expresiones de paquete
          para todos aquellos paquetes que no estén todavía en Guix.

     La siguiente orden importa los metadatos de la última versión del
     paquete Haskell HTTP sin incluir las dependencias de las pruebas y
     especificando la opción ‘network-uri’ con valor ‘false’:

          guix import hackage -t -e "'((\"network-uri\" . false))" HTTP

     Se puede especificar opcionalmente una versión específica del
     paquete añadiendo al nombre del paquete una arroba y el número de
     versión como en el siguiente ejemplo:

          guix import hackage mtl@2.1.3.1

‘stackage’
     El importador ‘stackage’ es un recubrimiento sobre el de ‘hackage’.
     Toma un nombre de paquete, busca la versión de paquete incluida en
     una publicación de la versión de mantenimiento extendido (LTS)
     Stackage (https://www.stackage.org) y usa el importador ‘hackage’
     para obtener sus metadatos.  Fíjese que es su decisión seleccionar
     una publicación LTS compatible con el compilador GHC usado en Guix.

     Las opciones específicas de línea de ordenes son:

     ‘--no-test-dependencies’
     ‘-t’
          No incluye las dependencias necesarias únicamente para las
          baterías de pruebas.
     ‘--lts-version=VERSIÓN’
     ‘-l VERSIÓN’
          VERSIÓN es la versión LTS de publicación deseada.  Si se omite
          se usa la última publicación.
     ‘--recursive’
     ‘-r’
          Recorre el grafo de dependencias del paquete original
          proporcionado recursivamente y genera expresiones de paquete
          para todos aquellos paquetes que no estén todavía en Guix.

     La siguiente orden importa los metadatos del paquete Haskell HTTP
     incluido en la versión de publicación LTS de Stackage 7.18:

          guix import stackage --lts-version=7.18 HTTP

‘elpa’
     Importa metadatos desde el repositorio de archivos de paquetes
     Emacs Lisp (ELPA) (*note (emacs)Packages::).

     Las opciones específicas de línea de ordenes son:

     ‘--archive=REPO’
     ‘-a REPO’
          REPO identifica el repositorio de archivos del que obtener la
          información.  Actualmente los repositorios disponibles y sus
          identificadores son:
             - GNU (https://elpa.gnu.org/packages), seleccionado con el
               identificador ‘gnu’.  Utilizado de manera predeterminada.

               Los paquetes de ‘elpa.gnu.org’ están firmados con una de
               las claves que contiene el anillo de claves GnuPG en
               ‘share/emacs/25.1/etc/package-keyring.gpg’ (o similar) en
               el paquete ‘emacs’ (*note ELPA package signatures:
               (emacs)Package Installation.).

             - NonGNU (https://elpa.nongnu.org/nongnu/), selected by the
               ‘nongnu’ identifier.

             - MELPA-Stable (https://stable.melpa.org/packages),
               seleccionado con el identificador ‘melpa-stable’.

             - MELPA (https://melpa.org/packages), seleccionado con el
               identificador ‘melpa’.

     ‘--recursive’
     ‘-r’
          Recorre el grafo de dependencias del paquete original
          proporcionado recursivamente y genera expresiones de paquete
          para todos aquellos paquetes que no estén todavía en Guix.

‘crate’
     Importa metadatos desde el repositorio de paquetes Rust crates.io
     (https://crates.io), como en este ejemplo:

          guix import crate blake2-rfc

     El importador de crate también le permite especificar una cadena de
     versión:

          guix import crate constant-time-eq@0.1.0

     La opciones adicionales incluyen:

     ‘--recursive’
     ‘-r’
          Recorre el grafo de dependencias del paquete original
          proporcionado recursivamente y genera expresiones de paquete
          para todos aquellos paquetes que no estén todavía en Guix.

‘elm’
     Import metadata from the Elm package repository
     package.elm-lang.org (https://package.elm-lang.org), as in this
     example:

          guix import elm elm-explorations/webgl

     The Elm importer also allows you to specify a version string:

          guix import elm elm-explorations/webgl@1.1.3

     La opciones adicionales incluyen:

     ‘--recursive’
     ‘-r’
          Recorre el grafo de dependencias del paquete original
          proporcionado recursivamente y genera expresiones de paquete
          para todos aquellos paquetes que no estén todavía en Guix.

‘opam’
     Importa metadatos desde el repositorio de paquetes OPAM
     (https://opam.ocaml.org/) usado por la comunidad OCaml.

     La opciones adicionales incluyen:

     ‘--recursive’
     ‘-r’
          Recorre el grafo de dependencias del paquete original
          proporcionado recursivamente y genera expresiones de paquete
          para todos aquellos paquetes que no estén todavía en Guix.
     ‘--repo’
          By default, packages are searched in the official OPAM
          repository.  This option, which can be used more than once,
          lets you add other repositories which will be searched for
          packages.  It accepts as valid arguments:

             • the name of a known repository - can be one of ‘opam’,
               ‘coq’ (equivalent to ‘coq-released’), ‘coq-core-dev’,
               ‘coq-extra-dev’ or ‘grew’.
             • the URL of a repository as expected by the ‘opam
               repository add’ command (for instance, the URL equivalent
               of the above ‘opam’ name would be
               <https://opam.ocaml.org>).
             • the path to a local copy of a repository (a directory
               containing a ‘packages/’ sub-directory).

          Repositories are assumed to be passed to this option by order
          of preference.  The additional repositories will not replace
          the default ‘opam’ repository, which is always kept as a
          fallback.

          Also, please note that versions are not compared across
          repositories.  The first repository (from left to right) that
          has at least one version of a given package will prevail over
          any others, and the version imported will be the latest one
          found _in this repository only_.

‘go’
     Import metadata for a Go module using proxy.golang.org
     (https://proxy.golang.org).

          guix import go gopkg.in/yaml.v2

     It is possible to use a package specification with a ‘@VERSION’
     suffix to import a specific version.

     La opciones adicionales incluyen:

     ‘--recursive’
     ‘-r’
          Recorre el grafo de dependencias del paquete original
          proporcionado recursivamente y genera expresiones de paquete
          para todos aquellos paquetes que no estén todavía en Guix.
     ‘--pin-versions’
          When using this option, the importer preserves the exact
          versions of the Go modules dependencies instead of using their
          latest available versions.  This can be useful when attempting
          to import packages that recursively depend on former versions
          of themselves to build.  When using this mode, the symbol of
          the package is made by appending the version to its name, so
          that multiple versions of the same package can coexist.

‘egg’
     Import metadata for CHICKEN eggs (https://wiki.call-cc.org/eggs).
     The information is taken from ‘PACKAGE.egg’ files found in the
     eggs-5-all (git://code.call-cc.org/eggs-5-all) Git repository.
     However, it does not provide all the information that we need,
     there is no “description” field, and the licenses used are not
     always precise (BSD is often used instead of BSD-N).

          guix import egg sourcehut

     You can also ask for a specific version:

          guix import egg arrays@1.0

     La opciones adicionales incluyen:
     ‘--recursive’
     ‘-r’
          Recorre el grafo de dependencias del paquete original
          proporcionado recursivamente y genera expresiones de paquete
          para todos aquellos paquetes que no estén todavía en Guix.

‘hexpm’
     Import metadata from the hex.pm Erlang and Elixir package
     repository hex.pm (https://hex.pm), as in this example:

          guix import hexpm stun

     The importer tries to determine the build system used by the
     package.

     The hexpm importer also allows you to specify a version string:

          guix import hexpm cf@0.3.0

     La opciones adicionales incluyen:

     ‘--recursive’
     ‘-r’
          Recorre el grafo de dependencias del paquete original
          proporcionado recursivamente y genera expresiones de paquete
          para todos aquellos paquetes que no estén todavía en Guix.

   La estructura del código de ‘guix import’ es modular.  Sería útil
tener más importadores para otros formatos de paquetes, y su ayuda es
bienvenida aquí (*note Contribuir::).

