From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id 0AqVMDWZxGGoWgEAgWs5BA (envelope-from ) for ; Thu, 23 Dec 2021 16:43:49 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id oPALLDWZxGGZOAAAbx9fmQ (envelope-from ) for ; Thu, 23 Dec 2021 15:43:49 +0000 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 5B19914B12 for ; Thu, 23 Dec 2021 16:43:49 +0100 (CET) Received: from localhost ([::1]:60134 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n0QFw-0004Qm-Fx for larch@yhetil.org; Thu, 23 Dec 2021 10:43:48 -0500 Received: from eggs.gnu.org ([209.51.188.92]:34624) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n0Pus-0005Ve-1B for guix-patches@gnu.org; Thu, 23 Dec 2021 10:22:02 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:51318) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n0Pur-0005z6-LE for guix-patches@gnu.org; Thu, 23 Dec 2021 10:22:01 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1n0Pur-0004FL-IZ for guix-patches@gnu.org; Thu, 23 Dec 2021 10:22:01 -0500 X-Loop: help-debbugs@gnu.org Subject: [bug#52600] [PATCH] doc: Document (gnu services configuration). Resent-From: Attila Lendvai Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Thu, 23 Dec 2021 15:22:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 52600 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Xinglu Chen Cc: Ludovic =?UTF-8?Q?Court=C3=A8s?= , 52600@debbugs.gnu.org, Maxim Cournoyer , Andrew Tropin Received: via spool by 52600-submit@debbugs.gnu.org id=B52600.164027288416278 (code B ref 52600); Thu, 23 Dec 2021 15:22:01 +0000 Received: (at 52600) by debbugs.gnu.org; 23 Dec 2021 15:21:24 +0000 Received: from localhost ([127.0.0.1]:34631 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n0PuF-0004ET-K0 for submit@debbugs.gnu.org; Thu, 23 Dec 2021 10:21:24 -0500 Received: from mail-4317.proton.ch ([185.70.43.17]:45594) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n0PuD-0004EG-Th for 52600@debbugs.gnu.org; Thu, 23 Dec 2021 10:21:22 -0500 Date: Thu, 23 Dec 2021 15:21:10 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lendvai.name; s=protonmail3; t=1640272874; bh=noMfY8Q3U7bw2EVNDN2QuvcpD/nlKbGIa+bQhhQZfC8=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:From:To:Cc; b=sre+Q4FoGcKn78i+/8fl70iq/fKcA4pdVp4n6Kux5ADpf0kSALrHykxm+/VcmkjfC TGL2pyRys0gsE64S15fAKrMKICkag7sdLlyiIM27N3pO5JXJVeeMUpeN0sNK0XaVJ7 OahhXWYGCC8uBnOgzH5OwUWorS4nPPVduKp2aEenXq4R7vwDlUC8AjA0qKAEGyWcuM Rbs8Sh+vK1F+AITY2kzasCXxceSUn8hAo+edeqfckWDMlhpHNLrirbTlOlmhHVttEc /xunaHhMTZqTxS9CNYbm6KiSvMt/9H90HGksfTR4217TmH/1f8gwQlGAf0WYFclOBr N5sVBhZL4TzUw== From: Attila Lendvai Message-ID: In-Reply-To: <87a6grcwh7.fsf@yoctocell.xyz> References: <665c4d2070de80af1d3594a268f0f6d3fb596d15.1639839498.git.public@yoctocell.xyz> <877dbwz3r7.fsf@gnu.org> <87ilvfd2lx.fsf@yoctocell.xyz> <87a6grcwh7.fsf@yoctocell.xyz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-Mailman-Approved-At: Thu, 23 Dec 2021 10:43:36 -0500 X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Attila Lendvai Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: "Guix-patches" X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1640274229; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: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=noMfY8Q3U7bw2EVNDN2QuvcpD/nlKbGIa+bQhhQZfC8=; b=HN4Tkf79FcQCja0zMfQdF4bSGikxiInFVsUsmJgb3xIg7p+WwifvoKmvqw4xe2RPJ7GgLX g4LNNQBsNVtiyqzhvgP3Xmv3CKPo9uNh9QYi9FC7DdEy/akAtFMXDe6pfqkkr0P9w7jE8j udROYZHZe36WhLm/GXAdXIhqGABeB/8r0j3RViVB9IHPqJJrvCIR8ObJ2ul/OSRyrCx1Tl XCS/v8SzWnJsq5SL1AO4eegqPf6tGwCztj3eTO7Nd2jCMDUs/0T98sMCDTu7fAZgAas2Xo pzVRbaj0HYu+YiVYY5H+GDtQxM5xHAIozbuFwWYf9eSm4R+m6j5vBv6g+FmxTw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1640274229; a=rsa-sha256; cv=none; b=Blfoms45+unGD0Uz0RN1Bjjj8wTv5ZoxX96ugXvoWaBGdGOs05NKmXmDlumgzzHIk4v1U6 Jqzo488r7P109pxNeqrhQumE14ZlEeqnlWCWfqk4/MM83iAxt8guwfjJzUpnkZ0ZLYPU2g AsbIDNYrPSTLcRLXsGN6l7Uyqouwr9S2mv19TwBIz0PiXA/lparA6f0dkuCiwAeLON69Ph r4GXdEERCSeQGDwJkS3wc9m8jCUCEFAJlp5ivNOBzjuXOsa8g0TX1jkOwvajAPcgayszGQ hPOzMbJeuwys4H6U9nwHjmKgFTDm2Om4nKiOR8tfnT68HvO6BOeCfsRU1r0Xkw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=lendvai.name header.s=protonmail3 header.b=sre+Q4Fo; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -0.85 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=lendvai.name header.s=protonmail3 header.b=sre+Q4Fo; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 5B19914B12 X-Spam-Score: -0.85 X-Migadu-Scanner: scn0.migadu.com X-TUID: OampUR7u5O/P > > i was expecting it to be possible to have a field like: > > > > (foo > > (maybe-integer?)) > > A =E2=80=98maybe-=E2=80=99 type doesn=E2=80=99t necessarily have to have = a default value set to > =E2=80=98disabled=E2=80=99. The default value of the =E2=80=98foo= =E2=80=99 field could just as well be > =E2=80=983=E2=80=99 or something. i know. but what i want is a field that is not initialized to any value, and a way to identify that fact in the service code (e.g. to derive a default value from another field). example: my service has a swarm-name field, and the service's unix user name is derived from it as "swarm-${swarm-name}" -- unless it is set by the user and overrides it, that is. in this case i can't set the field using the default value mechanism of define-configuration (i.e. at construction-time), because the default value is not a constant. the derivation of the default value must be done by the service's code, and it must be able to detect fields that were not set (i'm deliberately staying away from the word 'undefined' here, because the current codebase uses it, together with "disabled", in a strange way). > > and its behavior would be to hold an undocumented value by default, > > that the service implementations need to check for using a public > > predicate function. > > What do you mean by =E2=80=9Cundocumented value=E2=80=9D? a value that is opaque to the user, and can only be detected by a predicate (and possibly constructed by another function or through an exported global variable). > > some of the config values in my service can conditionally derive its > > default value based on the value of other fields. > > I don=E2=80=99t think this is possible with =E2=80=98define-configuration= =E2=80=99 yet. But it > would be a nice feature to have. i don't think it belongs to the define-configuration macro, because it would greatly increase the complexity of its DSL/implementation for little in return; one can always cover the few complex cases from the scheme code of the service. > > i need to be able to differentiate between undefined or user provided > > field values (i.e. completely independent of anything related to > > serialization). > > Maybe we could change =E2=80=98undefined=E2=80=99 to instead be an except= ion, which will > raised when the user doesn=E2=80=99t provide anything. that would make the above example/scenario impossible. although... you're probably using 'undefined' in the strange way that it is currently used in the code. i think the nomenclature should be clarified (regardless of what's in the current codebase). here's my proposal: 1) undefined: no value was provided, neither at construction time, nor as a default value in define-configuration. 2) missing: a value must be provided at construction time, but it wasn't. signalling an error at construction time in case of 'missing' is probably a good idea. but then 2) is mostly covered by the type predicates already, no? if i define the type as INTEGER? (i.e. not MAYBE-INTEGER?), then it'll already signal an error in that case. > > maybe we should use guile's undefined, and undefined? predicate > > (which is sadly a macro). or reexport an undefined? function, and > > shadow guile's macro? it's messy, and guile specific. > > I am not familiar with Guile internals, but I think that > =E2=80=98#=E2=80=99 is just a thing that the pretty-printer = prints. Maybe it's also a special type/value (to the point that it has its own heap object tag in Guile for which Guile's UNDEFINED? macro checks for; see https://www.gnu.org/software/guile/manual/guile.html#index-undefined_003f). > we could use =E2=80=9Cproper=E2=80=9D Maybe types, like in SRFI-189[1]? > [1]: Using https://srfi.schemers.org/srfi-189/srfi-189.html i don't immediately see its benefits here, but i'll need to get more familiar with this srfi. thanks for the pointer! > > or maybe we could use a heap object of an unusual/private type in a > > global private variable to represent undefined field values, and add a > > public predicate to test for it. using a cons cell for this is > > tempting, but it would leak implementation details for fields of type > > cons?. i'm new to scheme, but the best candidate is maybe a private > > dummy record instance? > > But what if a user wants to set a field to =E2=80=98disabled=E2=80=99 (be= cause they > don=E2=80=99t want anything to get serialized), then that record would ha= ve to > be public. yes, but preferably through a global variable or a function. my point is that the object's type/content should be opaque for the users. > > i'd add a configuration-undefined-value? predicate, and also add a > > configuration-defined-value? whose semantics is to return the value > > itself, or #false when undefined. it comes handy in (or > > (defined-value? foo) 42) patterns for non-boolean fields. > > But what if the value itself is #f? You wouldn=E2=80=99t be able to disti= nguish > between the cases where the value is undefined and when the value is #f. it's a user error when it is used on fields that may legitimately hold the #false value. > I don=E2=80=99t really see a use of having that functionality; do you hav= e any > examples when this would be useful to have? an example: the unix-user field of a service. 1) not specified by the admin =3D> generate a default user name 2) admin sets it to a string =3D> use that as user name 3) admin sets it to undefined (whichever value/API we use to mark the undefined value) =3D> don't create a unix user for the service, run it as root instead. but again, i'm not advocating for define-configuration to support this use-case. this example can easily modelled by e.g. using 'run-as-root as the default value in define-configuration, and the service code checking for it. > The second paragraph explains this, no? Or do you think it can be > improved? true, that should be enough. i'm also realizing that i'm talking about 1) how to change the code in (guix service configuration) under a ticket that discusses 2) the documentation of the current codebase. i'll cook up a patch that implements what i'm trying to describe above, and which is flexible enough to cover my use-cases. and then 1) can be continued under that ticket. - attila