This changes the 'custom-serializer' field into a generic
'extra-args' field that can be extended to support new literals.
Within extra-args, the literals 'sanitizer' and 'serializer' allow
for user-defined sanitization and serialization procedures respectively.
The 'empty-serializer' was also added as a literal to be used as before.
To prevent confusion between the new “explicit” style of specifying
a sanitizer, and the old “implicit” style, the latter has been
deprecated, and a warning is issued if it is encountered.
* gnu/services/configuration.scm (define-configuration-helper):
Rename 'custom-serializer' to 'extra-args'. Add support for literals
'sanitizer', 'serializer' and 'empty-serializer'. Rename procedure
'field-sanitizer' to 'default-field-sanitizer' to avoid syntax clash.
Only define default field sanitizers if user-defined ones are absent.
(normalize-extra-args): New variable.
(<configuration-field>)[sanitizer]: New field.
* doc/guix.texi (Complex Configurations): Document the newly added
literals.
* tests/services/configuration.scm: Add tests for the new literals.
Signed-off-by: Liliana Marie Prikler <liliana.prikler@gmail.com>
* gnu/services/configuration.scm
(generate-documentation): Format a list of packages by their names.
Signed-off-by: Maxim Cournoyer <maxim.cournoyer@gmail.com>
'generic-serialize-alist' refers to (gnu home services version-control)
for usage examples but there's no such module.
* gnu/services/configuration.scm (generic-serialize-alist): Adjust
docstring.
Signed-off-by: Ludovic Courtès <ludo@gnu.org>
Fixes <https://issues.guix.gnu.org/59423>.
* gnu/services/configuration.scm (define-configuration-helper): Rename the
accessor of the %location field from "NAME-location" to
"NAME-source-location".
Signed-off-by: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Reported-by: Pierre Langlois <pierre.langlois@gmx.com>
This reverts commit 39e4e00f75, with fixes for
the guix home issues reported and another one found while reconfiguring berlin
in the subsequent commit.
This reverts commit 543d971ed2, and
its dependent commit 9b21cd2e9a, which
appear to have triggered a recent wave of ‘guix home’ regressions
involving (services (list (service home-bash-service-type))):
In gnu/home/services/shells.scm:
504:7 3 (home-bash-extensions #<<home-bash-configuration> package: #<package bash@5.1.8 gnu/packages/ba…> …)
In unknown file:
2 (append #<<location> file: "…" line: 14 column: 12> ())
In ice-9/boot-9.scm:
1685:16 1 (raise-exception _ #:continuable? _)
1685:16 0 (raise-exception _ #:continuable? _)
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
In procedure append: Wrong type argument in position 1 (expecting empty list): #<<location> file: "…" line: 14 column: 12>
I should love to dive in & fix this rather than revert, but urgently
need sleep.
This is so that the first field of the generated record matches the first one
declared, which makes 'define-configuration' record API compatible with
define-record-type* ones.
* gnu/services/configuration.scm (define-configuration-helper): Move the
%location field below the ones declared by the user.
* gnu/services/monitoring.scm (zabbix-front-end-config): Adjust match pattern
accordingly.
The new value of %unset-value sticks out more when something goes wrong, and
is also more unique; i.e. easier to search for.
Signed-off-by: Maxim Cournoyer <maxim.cournoyer@gmail.com>
* gnu/services/configuration.scm (%unset-value): New variable.
(normalize-field-type+def): Use it.
(maybe-value-unset?): Use it.
Signed-off-by: Maxim Cournoyer <maxim.cournoyer@gmail.com>
* gnu/services/configuration.scm (maybe-value-set?): New procedure.
* doc/guix.texi (Complex Configurations): Document it. Remove comment showing
usage of 'maybe-string' with a default value, which doesn't make sense.
Co-authored-by: Attila Lendvai <attila@lendvai.name>
Fixes <https://issues.guix.gnu.org/56799>.
This partially reverts 8cb1a49a39.
Rationale: *unspecified* cannot be serialized thus used as a G-Expression
input, which is problematic/inconvenient when using deeply nested records. As
an example, jami-service-type was broken when using partially defined
<jami-account> records.
* gnu/services/configuration.scm (define-maybe-helper): Check against the
'unset symbol.
(normalize-field-type+def): Adjust value to 'unset.
(define-configuration-helper): Use 'unset as the default value thunk.
* gnu/services/file-sharing.scm (serialize-maybe-string): Check against the
'unset symbol.
(serialize-maybe-file-object): Likewise.
* gnu/services/messaging.scm (define-all-configurations): Use 'unset as
value.
(raw-content?): Check against 'unset symbol.
(prosody-configuration)[http-max-content-size]: Default to 'unset.
[http-external-url]: Likewise.
[mod-muc]: Likewise.
[raw-content]: Likewise.
* gnu/services/networking.scm (opendht-configuration): Adjust documentation.
* gnu/services/telephony.scm (jami-shepherd-services): Replace *undefined*
with the 'unset symbol.
* tests/services/configuration.scm ("maybe type, no default"): Check against
the 'unset symbol.
* doc/guix.texi: Regenerate the opendht-configuration,
openvpn-client-configuration and openvpn-server-configuration documentation.
Now that configuration records use the 'sanitize' property for each
field, 'validate-configuration' has become useless because it's
impossible to construct an invalid configuration record.
* gnu/services/configuration.scm (validate-configuration): Remove.
* gnu/services/mail.scm (dovecot-service): Remove call.
* gnu/services/vpn.scm (openvpn-client-service)
(openvpn-server-service): Likewise.
* doc/guix.texi (Complex Configurations): Remove documentation.
Previously field type errors would be reported in a non-standard way,
and without any source location information. This fixes it.
* gnu/services/configuration.scm (configuration-field-error): Add a
'loc' parameter and honor it. Use 'formatted-message' instead of plain
'format'.
(define-configuration-helper)[field-sanitizer]: New procedure.
Use it. Use STEM as the identifier of the syntactic constructor of the
record type. Add a 'sanitize' property to each field. Remove now
useless STEM macro that would call 'validate-configuration'.
* gnu/services/mail.scm (serialize-listener-configuration): Adjust to
new 'configuration-field-error' prototype.
* tests/services/configuration.scm ("wrong type for a field"): New test.
* po/guix/POTFILES.in: Add gnu/services/configuration.scm.
Use *unspecified* as a marker for field values that have not been set.
Rationale: 'disabled may easily clash with user values for boolean fields, is
confusing (i.e. its meaning is *not* boolean false, but unspecified) and it
also passes silently through the symbol? predicate of a field of type symbol.
* gnu/services/configuration.scm (configuration-missing-default-value):
Renamed from configuration-no-default-value.
(define-maybe-helper): Use *unspecified* instead of 'disabled, and make
the default value optional.
* gnu/home/services/desktop.scm (home-redshift-configuration):
Change (maybe-xyz 'disabled) to maybe-xyz.
* gnu/services/authentication.scm (nslcd-configuration): Likewise.
* gnu/services/cgit.scm (repository-cgit-configuration): Likewise.
* gnu/services/file-sharing.scm (serialize-maybe-string)
(serialize-maybe-file-object): Use 'unspecified?' instead of (eq? val
'disabled).
* gnu/services/messaging.scm (raw-content?): Likewise.
(ssl-configuration): Change (maybe-xyz 'disabled) to maybe-xyz.
(prosody-configuration): Likewise.
* gnu/services/file-sharing.scm (transmission-daemon-configuration):
Likewise.
* gnu/services/messaging.scm (define-all-configurations):
Use *unspecified* instead of 'disabled'.
* gnu/services/networking.scm (opendht-configuration): Likewise.
* gnu/services/pm.scm (tlp-configuration): Likewise.
* gnu/services/telephony.scm (jami-account): Likewise.
(jami-configuration): Likewise.
* gnu/services/vpn.scm (openvpn-client-configuration): Likewise.
* tests/services/configuration.scm ("maybe type, no default")
("maybe type, with default"): New tests.
Signed-off-by: Ludovic Courtès <ludo@gnu.org>
As opposed to explicitly using 'disabled as value, or using the
(field1 (maybe-number) "") format.
It's mostly the work of Maxime Devos shared under #54674, with some
modifications by Attila Lendvai.
* gnu/services/configuration.scm (normalize-field-type+def): New function.
(define-configuration-helper) (define-configuration): Support new field
format.
* tests/services/configuration.scm (config-with-maybe-number->string): New
function.
("maybe value serialization of the instance"): New test.
("maybe value serialization of the instance, unspecified"): New test.
Signed-off-by: Ludovic Courtès <ludo@gnu.org>
If the type of a configuration field is a package, show the name of its
package *variable* as the default value.
* gnu/services/configuration.scm (generate-documentation){show-default}
{package->symbol}: New nested procedures. Use them to format the field
entries.
Co-authored-by: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Signed-off-by: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Make the formatting of the generated docs more consistent with the rest of the
docs in the “Services” section of the manual.
* gnu/services/configuration (generate-documentation): Represent the data type
documentation of a field using a DEFTP table rather than DEFTYPEVR elements.
Modified-by: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Signed-off-by: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Sometimes two configurations might have the same types for their field values,
but the values might be serialized in two completely different
ways (e.g. because the two programs have different configuration languages).
An example of this would be the ‘serialize-boolean’ procedure in (gnu services
mail) and (gnu services getmail). They both serialize a boolean value, but
because the Dovecot’s configuration language has a different syntax to the
configuration language for Getmail, two different procedures have to be
defined.
One way to workaround this would be to specify custom serializers for many
fields in order to separate the serialization of the values that have the same
type but serialize in different ways. This could get very tedious, especially
if there are many configurations in the same module.
Another way would be to move one of the configurations to its own module, like
what was done with (gnu services getmail). However, this would mean that
there would be multiple modules containing configurations for related
programs, e.g. we have (gnu services mail) and (gnu services getmail), it
doesn’t make much sense to keep the Getmail configuration in its own module.
This patch will allow one to write something like this:
(define-configuration foo-configuration
(bar
(string "bob")
"Option bar.")
(prefix bar-))
and the value of the ‘bar’ field would be serialized using a procedure named
‘bar-serialize-string’ instead of just ‘serialize-string’.
* gnu/services/configuration.scm (define-maybe-helper): Accept ‘prefix’
argument for using serializer with custom prefix.
(define-maybe): Pattern match on ‘prefix’ literal.
(define-configuration-helper): Accept ‘prefix’ argument for using serializer
with custom prefix.
(define-configuration): Pattern match on ‘prefix’ literal.
* tests/services/configuration.scm ("serialize-configuration with prefix"):
New test.
Signed-off-by: Ludovic Courtès <ludo@gnu.org>
This is added for convenience and for uniformity with the
define-maybe/no-serialization syntax introduced in the previous commit.
* gnu/services/configuration.scm
(define-configuration/no-serialization): New syntax.
Before this change, using define-maybe along define-configuration with the
no-serialization syntactic keyword would result in the following warning:
warning: possibly unbound variable `VARIABLE-NAME'
This change introduces the define-maybe/no-serialization variant that does
away with defining a serialization helper procedure, which makes it possible
to avoid the above warning.
* gnu/services/configuration.scm (define-maybe/no-serialization): New syntax.
(define-maybe-helper): New procedure.
(define-maybe): Define syntax using the above procedure.
* tests/services/configuration.scm (tests): Fix module name.
(custom-number-serializer): Do not print to standard output.
(maybe-number?, serialize-maybe-number): New procedures defined via the
define-maybe macro.
(config-with-maybe-number): New configuration.
(serialize-number): New procedure.
("maybe value serialization"): New test.
(maybe-string?): New procedure defined via the define-maybe/no-serialization
macro.
(config-with-maybe-string/no-serialization): New configuration.
("maybe value without serialization no procedure bound"): New test.
The non-hygienic binding of the source location accessor was set to
'-location'; in modules where multiple configurations were defined, it would
cause compilation warnings such as:
gnu/services/mail.scm:175:0: warning: shadows previous definition of
`%-location-procedure' at gnu/services/mail.scm:165:0
* gnu/services/configuration.scm (define-configuration-helper) <id>: Add a
missing #'stem argument to use the configuration name as a prefix to the
location accessor identifier.
In some cases, rather than globally disabling serialization, it may be more
appropriate to disable or otherwise alter the serialization procedure of a
specific field. In large module, multiple configurations may also exist that
would need to alter the default serialization procedure, which is named after
the field type. Being able to specify a per-field serialization procedure
provides more flexibility.
* gnu/services/configuration.scm (define-configuration): Add an optional
pattern variable to allow specifying a custom serialization procedure.
(define-configuration-helper) <field-serializer>: Use it to transform the
syntax.
(empty-serializer): New procedure.
(serialize-package): Alias to ‘empty-serializer’.
Signed-off-by: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Serialization is not always useful, for example when deriving command line
arguments from a configuration. This change provides a way to turn it off,
which removes the need to define a bunch of dummy serialization procedures.
Credit goes to Andrew Gierth (RhodiumToad) from #guile for providing the
solution. Thank you!
* gnu/services/configuration.scm (define-configuration-helper): New procedure.
(define-configuration) <no-serialization>: New syntactic keyword. Use it in a
new pattern. Refactor the macro so that it makes use of the above helper
procedure.
This resolves a compilation warning introduced with commit bb716e8d9d.
* gnu/services/configuration.scm (configuration->documentation): Use display
to print the string instead of format.
The original (undocumented) procedure to generate the doc has a difficult to
grasp interface; add a simpler one on top of it.
* gnu/services/configuration.scm (configuration->documentation): New procedure.
Not all fields in a configuration have a sensible default value. This changes
makes it possible to omit a default value for a configuration field, requiring
the user to provide a value.
* gnu/services/configuration.scm (configuration-missing-field): New procedure.
(define-configuration): Make default value optional.
Signed-off-by: Maxim Cournoyer <maxim.cournoyer@gmail.com>
* doc/guix.texi (Messaging Services): Update accordingly.
* gnu/services/configuration.scm (serialize-configuration,
serialize-maybe-stem, serialize-package): Return strings or string-valued
gexps (these procedures were only used for their side-effects).
* gnu/services/messaging.scm (serialize-field, serialize-field-list,
enclose-quotes, serialize-raw-content, serialize-ssl-configuration,
serialize-virtualhost-configuration-list,
serialize-int-component-configuration-list,
serialize-ext-component-configuration-list,
serialize-virtualhost-configuration, serialize-int-component-configuration,
serialize-ext-component-configuration, serialize-prosody-configuration):
Return strings or string-valued gexps and stop printing.
(prosody-activation): Use SERIALIZE-PROSODY-CONFIGURATION's return value with
MIXED-TEXT-FILE instead of using its output with PLAIN-FILE.
(serialize-non-negative-integer, serialize-non-negative-integer-list): Convert
numbers to strings.
(file-object?, serialize-file-object, file-object-list?,
serialize-file-object-list): New procedures.
(ssl-configuration)[capath, cafile], (prosody-configuration)[plugin-paths,
groups-file]: Replace FILE-NAME with FILE-OBJECT.
* guix/gexp.scm (file-like?): New exported procedure.
* doc/guix.texi (Messaging Services): Regenerate it.
* gnu/services/configuration.scm (show-default?): Check VAL rather than DEFAULT.
* gnu/services/messaging.scm (show-default?): Check VAL rather than DEFAULT.
(prosody-configuration)[modules-enabled]: Remove default value from docstring.
* gnu/services/configuration.scm (id): Replace it using the more concise
version found in messaging.scm.
Signed-off-by: Clément Lassieur <clement@lassieur.org>
* gnu/services/configuration.scm (id): New procedure extracted from
define-configuration.
(define-maybe): New exported procedure, moved from messaging.scm.
* gnu/services/messaging.scm (define-maybe): Remove it.
(id): Move declaration inside define-all-configurations which is now
the only caller procedure.
Signed-off-by: Clément Lassieur <clement@lassieur.org>
* gnu/services/configuration.scm (serialize-field, serialize-string)
(serialize-space-separated-string-list, space-separated-string-list?)
(serialize-file-name, file-name?, serialize-boolean): Move these functions...
* gnu/services/cups.scm: ...to this file.
* gnu/services/kerberos.scm: ...to this file.
Configuration syntaxes are very specific to services. Some services may have
the same configuration syntax, but none of them is common enough to be
abstracted in configuration.scm.
Signed-off-by: Clément Lassieur <clement@lassieur.org>
