From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id GGpiOWP/8mLjKgEAbAwnHQ (envelope-from ) for ; Wed, 10 Aug 2022 02:44:20 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id AD9VOWP/8mIK/wAA9RJhRA (envelope-from ) for ; Wed, 10 Aug 2022 02:44:19 +0200 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 A93052D48D for ; Wed, 10 Aug 2022 02:44:19 +0200 (CEST) Received: from localhost ([::1]:36484 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oLZpa-0002OQ-Dv for larch@yhetil.org; Tue, 09 Aug 2022 20:44:18 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:40556) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oLZpK-0002MN-EZ for bug-guix@gnu.org; Tue, 09 Aug 2022 20:44:03 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:55781) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oLZpK-0003cx-50 for bug-guix@gnu.org; Tue, 09 Aug 2022 20:44:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oLZpJ-000878-W3 for bug-guix@gnu.org; Tue, 09 Aug 2022 20:44:02 -0400 X-Loop: help-debbugs@gnu.org Subject: bug#56799: (gnu services configuration) usage of *unspecified* is problematic Resent-From: Maxim Cournoyer Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Wed, 10 Aug 2022 00:44:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56799 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 56799@debbugs.gnu.org, attila@lendvai.name Received: via spool by 56799-submit@debbugs.gnu.org id=B56799.166009219931132 (code B ref 56799); Wed, 10 Aug 2022 00:44:01 +0000 Received: (at 56799) by debbugs.gnu.org; 10 Aug 2022 00:43:19 +0000 Received: from localhost ([127.0.0.1]:45530 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oLZoc-000863-Co for submit@debbugs.gnu.org; Tue, 09 Aug 2022 20:43:18 -0400 Received: from mail-qt1-f170.google.com ([209.85.160.170]:33526) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oLZoY-00085p-Uo for 56799@debbugs.gnu.org; Tue, 09 Aug 2022 20:43:17 -0400 Received: by mail-qt1-f170.google.com with SMTP id u12so10172614qtk.0 for <56799@debbugs.gnu.org>; Tue, 09 Aug 2022 17:43:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:user-agent:message-id:in-reply-to:date:references :subject:cc:to:from:from:to:cc; bh=i1Jtu1pT8fQ0K1Cq6BYBOacEbQfo1soeVG3Qb3HMpDk=; b=Wkuhk727is6jgKDON/k9l1+1bnoEb600qiy5jJ13C1LPh64EFaoRrGLhMjVibcEnM+ nvbbtG+txOfBawu5Kwn1Ikk9vX+H4yVOqdgFHpKnl5uge17pTH20ZUlUsXG35XOmCHGU J9s6TEVeHYQeNodzb/SdKApy6XXrOWNDjKjO1LFVXmpcR9E7iI+aUTXvCdOxeCg13JeZ llZfOOEyH30p3n17XbnN6RoEk7zQzi/V+7OpqgS8ExVyfqt4mJm28h8kLWZ8foxukC1L mEogJB/MiKtgOa5Dq2DuExoKXSbR6TQ/BvvalX5ssgMvPwrpWLkJKcZt7Q36+/HFw9HI 8nzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:message-id:in-reply-to:date:references :subject:cc:to:from:x-gm-message-state:from:to:cc; bh=i1Jtu1pT8fQ0K1Cq6BYBOacEbQfo1soeVG3Qb3HMpDk=; b=m/bQ9avRt0jHg2M+jLrSxJ6WeC2D4vAUrSCBkBCkL5CPk6UgLPWCR8dav3RZ5Rr/lC 2LI104xzMka0TOoxNjoeul9lAFi3R51/GtVt0yYienQrH6PIfV/bs2Pv6vTFE5SW8utG n7sMdIzSLwXK8fn+yYwPMrn7szAO+gtdajOWcLfYqrj79ErKtkwnPUCmdE1jTFZhXGYU BWgOf4H7ZE1Vtm9vSxOXsPaoWUXKZyu0ygCSJdg4h1dUSPD90eCdvJWNa1Jbi9wmM+ut T9XCC5jMlDLEtWXpEZV3fLdnmvz6lLj82XHHg/YSoLgIuw7ILChdQUw6+IAfhS9fvRgm 6Byg== X-Gm-Message-State: ACgBeo37DgTGsGamemNVU29bPcAKGrpsgZFtrvz/LtZ0t1I556HloGZJ IjwyfrmGEbJOIvOQFwPTmfg= X-Google-Smtp-Source: AA6agR5Q+LT7J4fAgwDlprHQ2s8klfSPpBx2MSWdXYcca4WSmNoSwOVsamQSVs/lfHJ16dXsrbpA+g== X-Received: by 2002:ac8:7e89:0:b0:31f:3155:e9d with SMTP id w9-20020ac87e89000000b0031f31550e9dmr22528373qtj.477.1660092189238; Tue, 09 Aug 2022 17:43:09 -0700 (PDT) Received: from hurd (dsl-10-135-11.b2b2c.ca. [72.10.135.11]) by smtp.gmail.com with ESMTPSA id k5-20020a05620a414500b006b93ef659c3sm8155659qko.39.2022.08.09.17.43.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Aug 2022 17:43:08 -0700 (PDT) From: Maxim Cournoyer References: <87o7xa8qxt.fsf@gmail.com> <8735egxedv.fsf@gnu.org> <87les82c2f.fsf@gmail.com> <87v8rbumnx.fsf@gnu.org> <87sfme1y8m.fsf@gmail.com> <877d3omc9c.fsf@gnu.org> Date: Tue, 09 Aug 2022 20:43:06 -0400 In-Reply-To: <877d3omc9c.fsf@gnu.org> ("Ludovic =?UTF-8?Q?Court=C3=A8s?="'s message of "Thu, 04 Aug 2022 14:19:59 +0200") Message-ID: <87bkstnd2d.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-guix@gnu.org List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+larch=yhetil.org@gnu.org Sender: "bug-Guix" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1660092259; 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:resent-cc:resent-from:resent-sender: resent-message-id:in-reply-to:in-reply-to:references:references: list-id:list-help:list-unsubscribe:list-subscribe:list-post: dkim-signature; bh=i1Jtu1pT8fQ0K1Cq6BYBOacEbQfo1soeVG3Qb3HMpDk=; b=P4w6UnyfisWm5LRbSv3yFakXCJwHGwUiTGoYYINBxdlfjMmhnc7rcDcbWyZGEwI05ibcOA qb/9XPrmnpkqAYSBzW74rYTQCuJR792Nim1yi2p/ZMj3zBfg8kOOxv2VpLeb3JCl/TW2he bBjzpWzaf91FNhM+KQfhOxyQMtT3tFNKG2P75jJWCKweFGSZJ95fPuCrNJintLCNfiuGVK nbc05/fpcHuWDU59PgbC5KwiVnrpxwkhpVHkK+T+OHKWDAm+WMKY1OSdLXvBc6u2YQyMJn 7bhrzkqNRoLNkf6ifGTHMX3bIaS+o7Dci1o6ZqsIn3E91UvJiDAvnjUbWhp1Zg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1660092259; a=rsa-sha256; cv=none; b=PWtXquzpXrk31LCgx9XsHZ6fcXyGd8ek2Sv59K6Ty1Hi8nThVyk/BRVnNTz/ArhuP5NMeJ hL/YgXjsH5hPna3kipYYphaOFMJVpaLlcsi7GdWA8QF4KdVJgqQAEK/cUjnf1E1BbOPWfk gcCsUUdM8fqxP4g9Nprbgz495ovWRCBwmodMJO2JpBTi9P6Vo2edi5Tszq9Xjjjfjr9+hn vhNRemdq+BUJRBW2bOvTIuRYSEhyfEmes/wfaotgLZyJjULAPeGEMApLcpSyWnSPz3OiID 4BvMacy1e29yzwitsu5JtJbuYjWxnG9WcnrQ9fZt80tXfGRohobh4OyLQQPFdA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=Wkuhk727; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of "bug-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="bug-guix-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: 4.81 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=Wkuhk727; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of "bug-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="bug-guix-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: A93052D48D X-Spam-Score: 4.81 X-Migadu-Scanner: scn0.migadu.com X-TUID: 407iCi6uINT3 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, Ludovic Court=C3=A8s writes: > Howdy, > > Maxim Cournoyer skribis: [...] >> I think mostly because few services make use of define-configuration. >> While attempting to write a new VNC service, it quickly became a visible >> annoyance: >> >> (define-configuration/no-serialization xvnc-configuration > > [...] > >> (port >> maybe-port >> "The port on which to listen for connections from viewers. When left >> unspecified, it defaults to 5900 plus the display number.") > > [...] > >> (define (xvnc-shepherd-service config) >> "Return a for Xvnc with CONFIG." >> ;; XXX: Ensure all the *unspecified* values are handled outside of gex= ps, as >> ;; they are not valid gexp input (they are not self-quoting/serializab= le). >> ;; This would otherwise cause problem during 'guix deploy'. >> (let* ((display-number (xvnc-configuration-display-number config)) >> (port (if (unspecified? (xvnc-configuration-port config)) >> #f >> (xvnc-configuration-port config))) > > OK, I see. I guess most of the time, we just call > =E2=80=98serialize-xyz-configuration=E2=80=99, which automatically handle= s *unspecified* > values. In this case, =E2=80=98port=E2=80=99 is treated specially and in= stead passed as > a command-line argument. Yes, and that provides much welcome flexibility, as records are serializable (as vectors) so long as the values they contain also are. > Other ways to address that come to mind include: adding =E2=80=98port=E2= =80=99 to the > config file instead of on the command line (if possible), or doing: > > (serialize-configuration config > (find (lambda (field) > (eq? (configuration-field-name field) > 'port)) > xvnc-configuration-fields)) > > That=E2=80=99s a mouthful but maybe it could be abstracted. It does soun= d less > convenient though. Xvnc takes no config switch, and I agree the above is not intuitive/great. It also wouldn't fix the use case of places it is more convenient to have the maybe value expanded into the gexp and dealt with there, such as used in the jami-service-type and in my previous example making use of a inetd style service, where shepherd-side only bindings such as endpoint makes it convenient to place the ports logic inside the service gexp. > That said, whether it=E2=80=99s =E2=80=98unspecified?=E2=80=99 or somethi= ng else, you have to > have a check in place, right? With the new interface it becomes: > > (if (eq? port 'unset) #f port) > > Or you can provide an actual default value (an integer in this case), > but that=E2=80=99s possible whether or not *unspecified* is the default v= alue. To me, the main use of maybe values is to allow for the daemon to use its own default when no value is specified. A maybe value with a default value makes little sense to me, so we should move toward eliminating that style and support for it from define-configuration, in my opinion. Things would be a bit easier to reason with then. As a baby step toward making 'unset a properly hidden implementation detail, I'd suggest the attached patch, which adds a means to check if a value was set. --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0001-services-configuration-Add-a-maybe-value-set-procedu.patch >From ac84f836a5a6c451465a879521a306b6fbcbed50 Mon Sep 17 00:00:00 2001 From: Maxim Cournoyer Date: Fri, 5 Aug 2022 15:03:55 -0400 Subject: [PATCH] services: configuration: Add a 'maybe-value-set?' procedure. * 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. --- doc/guix.texi | 7 ++++++- gnu/services/configuration.scm | 5 +++++ 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/doc/guix.texi b/doc/guix.texi index eb3a1a4eb5..ccdd01f321 100644 --- a/doc/guix.texi +++ b/doc/guix.texi @@ -38998,7 +38998,7 @@ to be a string, or left unspecified. (name ;; If set to a string, the `serialize-string' procedure will be used ;; to serialize the string. Otherwise this field is not serialized. - maybe-string ; equivalent to (maybe-string *unspecified*) + maybe-string "The name of this module.")) @end lisp @@ -39029,6 +39029,11 @@ whether its value is set or not. @end lisp @end deffn +@deffn (Scheme Procedure) maybe-value-set? @var{value} +Predicate to check whether a user explicitly specified the value of a +maybe field. +@end deffn + @deffn {Scheme Procedure} serialize-configuration @var{configuration} @ @var{fields} Return a G-expression that contains the values corresponding to the diff --git a/gnu/services/configuration.scm b/gnu/services/configuration.scm index 3007e8de35..b41b4d2e62 100644 --- a/gnu/services/configuration.scm +++ b/gnu/services/configuration.scm @@ -57,6 +57,7 @@ (define-module (gnu services configuration) serialize-configuration define-maybe define-maybe/no-serialization + maybe-value-set? generate-documentation configuration->documentation empty-serializer @@ -300,6 +301,10 @@ (define-configuration stem (field field-type+def (define (empty-serializer field-name val) "") (define serialize-package empty-serializer) +(define (maybe-value-set? value) + "Predicate to check whether a 'maybe' value was explicitly provided." + (not (eq? 'unset value))) + ;; A little helper to make it easier to document all those fields. (define (generate-documentation documentation documentation-name) (define (str x) (object->string x)) -- 2.36.1 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable [...] > With the xvnc example, I better understand the kind of situation where > a field value might end up directly in a gexp, though I=E2=80=99m still u= nsure > whether use of *unspecified* really makes things worse. At least, > because it lacks a read syntax, the problem is caught early on; whereas > with 'unset, you might end up stuffing 'unset in your config file > without noticing. I've been experimenting a lot with define-configuration recently and it gives you little chance to shoot yourself in the foot; it knows maybe values are not to be serialized, and won't wrote such values to config files. Thanks, Maxim --=-=-=--