9.7 Invoking guix style

The guix style command helps users and packagers alike style their package definitions and configuration files according to the latest fashionable trends. It can either reformat whole files, with the --whole-file option, or apply specific styling rules to individual package definitions. The command currently provides the following styling rules:

• formatting package definitions according to the project’s conventions (see Formato del código);
• rewriting package inputs to the “new style”, as explained below.

The way package inputs are written is going through a transition (see Referencia de package, for more on package inputs). Until version 1.3.0, package inputs were written using the “old style”, where each input was given an explicit label, most of the time the package name:

(package
  ;; …
  ;; The "old style" (deprecated).
  (inputs `(("libunistring" ,libunistring)
            ("libffi" ,libffi))))

Today, the old style is deprecated and the preferred style looks like this:

(package
  ;; …
  ;; The "new style".
  (inputs (list libunistring libffi)))

Likewise, uses of alist-delete and friends to manipulate inputs is now deprecated in favor of modify-inputs (see Definición de variantes de paquetes, for more info on modify-inputs).

In the vast majority of cases, this is a purely mechanical change on the surface syntax that does not even incur a package rebuild. Running guix style -S inputs can do that for you, whether you’re working on packages in Guix proper or in an external channel.

La sintaxis general es:

guix style [options] package…

This causes guix style to analyze and rewrite the definition of package… or, when package is omitted, of all the packages. The --styling or -S option allows you to select the style rule, the default rule being format—see below.

To reformat entire source files, the syntax is:

guix style --whole-file file…

Las opciones disponibles se enumeran a continuación.

--dry-run

-n

Show source file locations that would be edited but do not modify them.

--whole-file

-f

Reformat the given files in their entirety. In that case, subsequent arguments are interpreted as file names (rather than package names), and the --styling option has no effect.

As an example, here is how you might reformat your operating system configuration (you need write permissions for the file):

guix style -f /etc/config.scm

--alphabetical-sort

-A

Place the top-level package definitions in the given files in alphabetical order. Package definitions with matching names are placed with versions in descending order. This option only has an effect in combination with --whole-file.

--styling=rule

-S rule

Apply rule, one of the following styling rules:

format

Format the given package definition(s)—this is the default styling rule. For example, a packager running Guix on a checkout (see Ejecución de Guix antes de estar instalado) might want to reformat the definition of the Coreutils package like so:

./pre-inst-env guix style coreutils

inputs

Rewrite package inputs to the “new style”, as described above. This is how you would rewrite inputs of package whatnot in your own channel:

guix style -L ~/my/channel -S inputs whatnot

Rewriting is done in a conservative way: preserving comments and bailing out if it cannot make sense of the code that appears in an inputs field. The --input-simplification option described below provides fine-grain control over when inputs should be simplified.

arguments

Rewrite package arguments to use G-expressions (see Expresiones-G). For example, consider this package definition:

(define-public my-package
  (package
    ;; …
    (arguments      ;old-style quoted arguments
     '(#:make-flags '("V=1")
       #:phases (modify-phases %standard-phases
                  (delete 'build))))))

Running guix style -S arguments on this package would rewrite its arguments field like to:

(define-public my-package
  (package
    ;; …
    (arguments
      (list #:make-flags #~'("V=1")
            #:phases #~(modify-phases %standard-phases
                         (delete 'build))))))

Note that changes made by the arguments rule do not entail a rebuild of the affected packages. Furthermore, if a package definition happens to be using G-expressions already, guix style leaves it unchanged.

--list-stylings

-l

List and describe the available styling rules and exit.

--load-path=directorio

-L directorio

Añade directorio al frente de la ruta de búsqueda de módulos de paquetes (see Módulos de paquetes).

--expression=expr

-e expr

Style the package expr evaluates to.

Por ejemplo, ejecutando:

guix style -e '(@ (gnu packages gcc) gcc-5)'

styles the gcc-5 package definition.

--input-simplification=policy

When using the inputs styling rule, with ‘-S inputs’, this option specifies the package input simplification policy for cases where an input label does not match the corresponding package name. policy may be one of the following:

silent

Simplify inputs only when the change is “silent”, meaning that the package does not need to be rebuilt (its derivation is unchanged).

safe

Simplify inputs only when that is “safe” to do: the package might need to be rebuilt, but the change is known to have no observable effect.

always

Simplify inputs even when input labels do not match package names, and even if that might have an observable effect.

The default is silent, meaning that input simplifications do not trigger any package rebuild.