From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id SGxFBvjvCWT8VwAASxT56A (envelope-from ) for ; Thu, 09 Mar 2023 15:40:56 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id MBitBfjvCWTdeQAAauVa8A (envelope-from ) for ; Thu, 09 Mar 2023 15:40:56 +0100 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id E28952725D for ; Thu, 9 Mar 2023 15:40:55 +0100 (CET) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=dismail.de header.s=20190914 header.b=O4VQ8A7A; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=reject) header.from=dismail.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1678372855; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=MmpJ+xhaV6bkoRFCLuKXIk/vxfwmMIwgKNQlQLys6xc=; b=KdvQhk8l0Kh3jJY5qMecbXfx2aFdqJCW0epBydWVZvCa5C+LIXWjyXgvFDP4eg1qUW3Mnd pVuc29z6FiC9ENWSoRAii1IJqdZ6YL6lOAE65DsGFZJXiQG1Q/cWLT+3pOQ640wuUk898o +ZRtukV6dQH2f/sMFzXs7S94O7K7uogLIbOBHfQV9v8c6/TJBSIMrB8LIR2UXlr0BaWRug aj0XtI8R+6zSZnGmnn+FAzSlkf9Keq3sCdgGiOyIP9iUpaj6fPhZAV5a6lx6gG9NwwPt+n It8oH9epBEXJoJ4amUPuY1sUHpaepKfPf8aMJuoaRCg4MoBSoQgLzlBAvD3DGg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1678372855; a=rsa-sha256; cv=none; b=t48EDfIS8n7hIq6UPla8N+pCcUg0HaP5gvPQr0kWEue4+RggD7Vw/+zHerx8Pok8zqf4V9 V7C4IAmh3lI+/hZI9rltqzKco3P9dwe7XOpOumEo0irN8Gdvb6wudMXQjHhBDegK8yMkyY d9jeI0zazayjjB+DkyG0laTj7FvvcTAfp+Kqstpwx2AX77swgO7Rv8fY4fjrZ5a5nUoXEv xao5+Eh7atknEYPxPWYdcDsG/aNmbqdravlZjmavgVrGa/g+wXvwRKqJYVbAsfOEQtXbuE EKcVKkh73iJ5+i91Cd/nMwK0mLbkRmC7nZ54R1gUpjJuSN+VzyEuQ/Wbb/UdoQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=dismail.de header.s=20190914 header.b=O4VQ8A7A; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=reject) header.from=dismail.de Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1paHRQ-0006AR-Gb; Thu, 09 Mar 2023 09:40:24 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1paHRO-00069l-Ca for guix-devel@gnu.org; Thu, 09 Mar 2023 09:40:22 -0500 Received: from mx1.dismail.de ([78.46.223.134]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1paHRM-000861-3g; Thu, 09 Mar 2023 09:40:22 -0500 Received: from mx1.dismail.de (localhost [127.0.0.1]) by mx1.dismail.de (OpenSMTPD) with ESMTP id 520d6455; Thu, 9 Mar 2023 15:40:14 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=dismail.de; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=20190914; bh=34KlaP+n0zU5lRyVu44PZ8jB+7t7IEAHB0 3hYEPGanE=; b=O4VQ8A7AbrhQmuUoZi5XvzfIjfg59JG7zCpY+LvzoI0pJt4WrE nGeyMispdRwtVVl+oX5N61OkwDVBqvJoJGzbLg81mb+UKuU21bOdCC8aiwtKPnY6 7YvcETjaOogWWaRj0L4t27bpZb2kseNjruaN/tHROKfXJ4Hd4AepOJ+ZFasBLw7D f7ELFAoIonDKymRw4KxN9mkKd3t66Du/ZdF7z7cWKTsiNNlP1/YA7+O4TiTFpw6J j5VZh9GLanTkqb9GqJ2cwpRuWhrUE3QMnlDWlLlZfmBKMO6H0hHbNtwGfTJemcpE QwRNQctIFEycrZJ69E4OueoLbrLIz3wRQg+g== Received: from smtp1.dismail.de ( [10.240.26.11]) by mx1.dismail.de (OpenSMTPD) with ESMTP id 878f2e8c; Thu, 9 Mar 2023 15:40:13 +0100 (CET) Received: from smtp1.dismail.de (localhost [127.0.0.1]) by smtp1.dismail.de (OpenSMTPD) with ESMTP id a7e9db38; Thu, 9 Mar 2023 15:40:13 +0100 (CET) Received: by dismail.de (OpenSMTPD) with ESMTPSA id e6d7eaee (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Thu, 9 Mar 2023 15:40:12 +0100 (CET) From: Joshua Branson To: Bruno Victal Cc: guix-devel , Felix Lechner , Liliana Marie Prikler , Maxim Cournoyer , Ludovic =?utf-8?Q?Court=C3=A8s?= Subject: Re: Brainstorming ideas for define-configuration References: X-Gnus-Sucks: I know man Date: Thu, 09 Mar 2023 09:40:03 -0500 In-Reply-To: (Bruno Victal's message of "Thu, 9 Mar 2023 02:28:01 +0000") Message-ID: <87bkl22dks.fsf@dismail.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=78.46.223.134; envelope-from=jbranso@dismail.de; helo=mx1.dismail.de X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: X-Migadu-Scanner: scn0.migadu.com X-Migadu-Queue-Id: E28952725D X-Spam-Score: -6.53 X-Migadu-Spam-Score: -6.53 List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: guix-devel-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-TUID: pazUQcKQiyCq Bruno Victal 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