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>
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>
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.
