summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
Diffstat (limited to 'doc')
-rw-r--r--doc/contributing.texi18
-rw-r--r--doc/guix.texi60
2 files changed, 59 insertions, 19 deletions
diff --git a/doc/contributing.texi b/doc/contributing.texi
index 72f5ce1e0e..9f97788c0b 100644
--- a/doc/contributing.texi
+++ b/doc/contributing.texi
@@ -959,17 +959,11 @@ If you do not use Emacs, please make sure to let your editor knows these
rules. To automatically indent a package definition, you can also run:
@example
-./etc/indent-code.el gnu/packages/@var{file}.scm @var{package}
+./pre-inst-env guix style @var{package}
@end example
@noindent
-This automatically indents the definition of @var{package} in
-@file{gnu/packages/@var{file}.scm} by running Emacs in batch mode. To
-indent a whole file, omit the second argument:
-
-@example
-./etc/indent-code.el gnu/services/@var{file}.scm
-@end example
+@xref{Invoking guix style}, for more information.
@cindex Vim, Scheme code editing
If you are editing code with Vim, we recommend that you run @code{:set
@@ -1039,6 +1033,10 @@ name of the new or modified package, and fix any errors it reports
(@pxref{Invoking guix lint}).
@item
+Run @code{guix style @var{package}} to format the new package definition
+according to the project's conventions (@pxref{Invoking guix style}).
+
+@item
Make sure the package builds on your platform, using @code{guix build
@var{package}}.
@@ -1175,8 +1173,8 @@ Examples of unrelated changes include the addition of several packages,
or a package update along with fixes to that package.
@item
-Please follow our code formatting rules, possibly running the
-@command{etc/indent-code.el} script to do that automatically for you
+Please follow our code formatting rules, possibly running
+@command{guix style} script to do that automatically for you
(@pxref{Formatting Code}).
@item
diff --git a/doc/guix.texi b/doc/guix.texi
index 601212fb45..7ffb0d738c 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -12785,8 +12785,16 @@ otherwise.
The @command{guix style} command helps packagers style their package
definitions according to the latest fashionable trends. The command
-currently focuses on one aspect: the style of package inputs. It may
-eventually be extended to handle other stylistic matters.
+currently provides the providing styling rules:
+
+@itemize
+@item
+formatting package definitions according to the project's conventions
+(@pxref{Formatting Code});
+
+@item
+rewriting package inputs to the ``new style'', as explained below.
+@end itemize
The way package inputs are written is going through a transition
(@pxref{package Reference}, for more on package inputs). Until version
@@ -12817,7 +12825,7 @@ Package Variants}, for more info on @code{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
-@command{guix style} can do that for you, whether you're working on
+@command{guix style -S inputs} can do that for you, whether you're working on
packages in Guix proper or in an external channel.
The general syntax is:
@@ -12827,15 +12835,48 @@ guix style [@var{options}] @var{package}@dots{}
@end example
This causes @command{guix style} to analyze and rewrite the definition
-of @var{package}@dots{}. It does so in a conservative way: preserving
-comments and bailing out if it cannot make sense of the code that
-appears in an inputs field. The available options are listed below.
+of @var{package}@dots{} or, when @var{package} is omitted, of @emph{all}
+the packages. The @option{--styling} or @option{-S} option allows you
+to select the style rule, the default rule being @code{format}---see
+below.
+
+The available options are listed below.
@table @code
@item --dry-run
@itemx -n
Show source file locations that would be edited but do not modify them.
+@item --styling=@var{rule}
+@itemx -S @var{rule}
+Apply @var{rule}, one of the following styling rules:
+
+@table @code
+@item format
+Format the given package definition(s)---this is the default styling
+rule. For example, a packager running Guix on a checkout
+(@pxref{Running Guix Before It Is Installed}) might want to reformat the
+definition of the Coreutils package like so:
+
+@example
+./pre-inst-env guix style coreutils
+@end example
+
+@item inputs
+Rewrite package inputs to the ``new style'', as described above. This
+is how you would rewrite inputs of package @code{whatnot} in your own
+channel:
+
+@example
+guix style -L ~/my/channel -S inputs whatnot
+@end example
+
+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 @option{--input-simplification} option described below provides
+fine-grain control over when inputs should be simplified.
+@end table
+
@item --load-path=@var{directory}
@itemx -L @var{directory}
Add @var{directory} to the front of the package module search path
@@ -12854,9 +12895,10 @@ guix style -e '(@@ (gnu packages gcc) gcc-5)'
styles the @code{gcc-5} package definition.
@item --input-simplification=@var{policy}
-Specify the package input simplification policy for cases where an input
-label does not match the corresponding package name. @var{policy} may
-be one of the following:
+When using the @code{inputs} styling rule, with @samp{-S inputs}, this
+option specifies the package input simplification policy for cases where
+an input label does not match the corresponding package name.
+@var{policy} may be one of the following:
@table @code
@item silent