unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Joshua Branson <jbranso@dismail.de>
To: Bruno Victal <mirai@makinata.eu>
Cc: guix-devel <guix-devel@gnu.org>,
	"Felix Lechner" <felix.lechner@lease-up.com>,
	"Liliana Marie Prikler" <liliana.prikler@gmail.com>,
	"Maxim Cournoyer" <maxim.cournoyer@gmail.com>,
	"Ludovic Courtès" <ludo@gnu.org>
Subject: Re: Brainstorming ideas for define-configuration
Date: Thu, 09 Mar 2023 09:40:03 -0500	[thread overview]
Message-ID: <87bkl22dks.fsf@dismail.de> (raw)
In-Reply-To: <ec01cb0c-e7f7-6824-1a4a-c2a45c789808@makinata.eu> (Bruno Victal's message of "Thu, 9 Mar 2023 02:28:01 +0000")

Bruno Victal <mirai@makinata.eu> writes:

> Co-authored-by: Felix Lechner
>
>
> After spending some time with old and new Guix services, I'd like to
> suggest some potential improvements to our define-configuration macro:
>
>
> User-specified sanitizer support
> ===============================================================================
>

Yes please!  Thanks for working on these improvements!  It would make my
opensmtpd-service updates much easier (though I haven't really touched
the code in a while).

https://issues.guix.gnu.org/56046

>
> The sanitizers should be integrated with the type. Otherwise, they are
> tedious to use and appear verbose when repeatedly applied to multiple fields.
>
> ;; Suggestion #1
> ;; The procedure could return a sanitized value. Upon failure, there are
> ;; the following options:
> ;;    - The procedure returns only a special value (akin to %unset-value)
> ;;      and an error message, as a pair.
> ;;      Exception raising is done by define-sanitized macro behind the scenes
> ;;      which makes the procedure easier to write.
> ;;    - The procedure raises an exception. There would be no consistency
> ;;      on the message formats, however, except for any agreed convention.
> ;;      This would involve some code duplication.
> ;; Cons: too specific, not extensible.
>
> (define-sanitized typename procedure
>   (prefix ...))
>
>
> ;; Suggestion #2
> ;; A user-supplied procedure ('procname' below) would work just like the
> ;; procedure in option #1.
> ;; There is some similiarity to the Guix record-type*.
> ;; This could be extended more easily in the future should it be required.
> (define-type typename        ; maybe call this 'define-configuration-type' ?
>   (sanitizer procname)
>   (maybe-type? #t)
>   ;; The properties below are service specific.
>   ;; If this is implemented with Guix record-type* then we could have a
>   ;; module containing generic types and do something along the lines of:
>   ;; (define-type foo-ip-address
>   ;;    (inherit generic-ip-address)
>   ;;    (serializer ...))
>   (serializer procname)      ; define-type/no-serialization = sets this field to #f ?
>   (prefix ...))
>
>
> Record Validator
> ===============================================================================
>
> There is also a need to validate records. Matching fields alone do not actually
> ensure that the configuration is coherent and usable. For example, some fields
> may be mutually incompatible with others.
>
> We could provide procedures that validate each record type within
> define-configuration itself instead of validating the value at runtime (i.e.
> within the body of the service-type).

This is also a great idea!

> Cheers,
> Bruno


  parent reply	other threads:[~2023-03-09 14:40 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-09  2:28 Brainstorming ideas for define-configuration Bruno Victal
2023-03-09  8:13 ` Attila Lendvai
2023-03-09 21:05   ` Josselin Poiret
2023-03-09 14:40 ` Joshua Branson [this message]
2023-03-09 20:23 ` Liliana Marie Prikler
2023-03-10 14:10 ` Maxim Cournoyer
2023-03-10 20:15 ` jbranso
2023-03-10 22:37   ` Liliana Marie Prikler
2023-03-15 16:27 ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87bkl22dks.fsf@dismail.de \
    --to=jbranso@dismail.de \
    --cc=felix.lechner@lease-up.com \
    --cc=guix-devel@gnu.org \
    --cc=liliana.prikler@gmail.com \
    --cc=ludo@gnu.org \
    --cc=maxim.cournoyer@gmail.com \
    --cc=mirai@makinata.eu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).