From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id +PWlDILyJmT2bAEASxT56A (envelope-from ) for ; Fri, 31 Mar 2023 16:47:30 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id AEOSDILyJmSNygAA9RJhRA (envelope-from ) for ; Fri, 31 Mar 2023 16:47:30 +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 DA179B588 for ; Fri, 31 Mar 2023 16:47:29 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1piG1r-0008KJ-JR; Fri, 31 Mar 2023 10:46:59 -0400 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 1piG1p-0008K6-VE for guix-devel@gnu.org; Fri, 31 Mar 2023 10:46:58 -0400 Received: from mail-qt1-x829.google.com ([2607:f8b0:4864:20::829]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1piG1o-0008QN-3l for guix-devel@gnu.org; Fri, 31 Mar 2023 10:46:57 -0400 Received: by mail-qt1-x829.google.com with SMTP id r5so21875845qtp.4 for ; Fri, 31 Mar 2023 07:46:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680274014; x=1682866014; h=mime-version:user-agent:message-id:in-reply-to:date:references :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=AX2G+604Bn3TTt2e3Ryy0MwS1tO55vSt5F3RV42rD6k=; b=JbHX7bSe0b2GuGOl38bgyxwY93/OlpphXxsJ0Opokhhyyr8Vw6+7QMItb0lOQxlYT8 M4b6uU8XEV0v2z7QA/fN4Wr2QzBNFgmzYZA9/8krWqtS1MgeVA9oPWVOkcvy19k+Ifgk ddVlemc7ETcTH4DeYSdOMPPY/GnfG8vYpuzWRUkpDCBoXHMRULsuqm0TrTfnMS/SBn+c DjRfa620TK84pgzoTLlCqr4TtAFHdnA0HAWa4qcjifPGUXjfplgvVbO1VwyMQI4sBtLj cv8FU2RpV1Pa3r4BsXJiwYUBFY7CbChZl5oiwMCj56/hn4+4iZtbreQLkEz636XTT0o3 +0RQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680274014; x=1682866014; h=mime-version:user-agent:message-id:in-reply-to:date:references :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=AX2G+604Bn3TTt2e3Ryy0MwS1tO55vSt5F3RV42rD6k=; b=yYYStKb7/22AtHjWFmv3+J+fo+07lEmKR2b99MiIfmawg0l2fey+moOGW1qzB1qtBD qAhDLv6T3EJKVsXHAhhtok+Ft5RZRIc13rhUDeuGKeNKvwmiBhtK+ftrswxIbKllQsug I6WNgTbCr/rQrFeEggCwQS0i59klYOo9inYqaDlMUelN28y632rf4GjmRh3Z0tpAnyUr D2oWGDpvfBNXhENA3O5GXMUtIJpDuoxZZNSsajm7Er62FnVZpNK+EhRuIzhE8turDIEK fThiszLV2kA7w0pWuDPYDmiHAQnQ7UaQmO5hzPexLrB7zD4kFm2GomsjzHxn4HAkvMHa Zi2w== X-Gm-Message-State: AAQBX9e6jBN1ufDT0JwO68K4FSk8M9HKBLuN1CEPU/17QeXjdA7yg2vS KLyJWoB9YIhjckGpeLsEtqzWbvW267IcgA== X-Google-Smtp-Source: AKy350bcBqXZK0yY6lhAlAEmy5X82NTy3Cw/ImFxVMD26dDZKR5MIyNSZvzH5H/T8anMJXRuRVA/Ig== X-Received: by 2002:a05:622a:407:b0:3e6:3257:94ba with SMTP id n7-20020a05622a040700b003e6325794bamr10505935qtx.29.1680274014439; Fri, 31 Mar 2023 07:46:54 -0700 (PDT) Received: from hurd (dsl-10-149-138.b2b2c.ca. [72.10.149.138]) by smtp.gmail.com with ESMTPSA id q21-20020a05620a2a5500b007426ec97253sm694814qkp.111.2023.03.31.07.46.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 31 Mar 2023 07:46:53 -0700 (PDT) From: Maxim Cournoyer To: Bruno Victal Cc: guix-devel Subject: Re: [RFC] Cosmetic changes to define-configuration usage References: Date: Fri, 31 Mar 2023 10:46:52 -0400 In-Reply-To: (Bruno Victal's message of "Fri, 24 Mar 2023 12:33:47 +0000") Message-ID: <87lejdvuzn.fsf@gmail.com> 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=2607:f8b0:4864:20::829; envelope-from=maxim.cournoyer@gmail.com; helo=mail-qt1-x829.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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: 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-Country: US X-Migadu-Flow: FLOW_IN ARC-Seal: i=1; s=key1; d=yhetil.org; t=1680274050; a=rsa-sha256; cv=none; b=AwrDy38VPCXKOtG/isMqmXB9+OYvLZICA893guKuCFD6/mUqSAFrRcp7Rj6YlrfHie1eNK 2Qkn1MNEXbAVoI5JphUSMSc2S5PxbDFvxjJLrsCGRQTN2rPn7mrjTzgzbofHbzguzSYvuH ywE5xVHIXwMImZi5zR0o8AXNy/VG7uRFq4L2AuHxPYokUgx+uYcK6IVegkFh3CmbbD+2JA 3PbX/h1wrJFW7zHwYpg3o4W+uuhox9I0OYl6EBQf5lOdZKBdDNStOh6OyG7X8HV+1dWxdv Jrg29vVn9n5kwA1DgeLbz6H8Y6TSmyinppX4ilnaM//9tE1lLPr2Qzbvv50dtg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=JbHX7bSe; dmarc=pass (policy=none) header.from=gmail.com; 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" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1680274050; 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=AX2G+604Bn3TTt2e3Ryy0MwS1tO55vSt5F3RV42rD6k=; b=XsIa0xQ04BOIXeefzvFEABt7IGXaLWRpYJZeijNnYoC0LVJBqQdyYvdCtG3QRPovw8yfdj 1ZvZ5XU7X2t4EsG8hmOnBfB2SJcuabXnaY39F+uD7GysKGwsPqux7XlRVbx5wpCIm0sufI 0XcKoz1ieha+7Skj7EQkNi0V1VE8lQ0XWdfxifzss2nmHSG/B6mXi57XQ5EOJiPHUp0c2J f6EBFP+0wCHshFxmXJWaykSq8qSI4lNvWzrKmfudslrie3V0+4Eah+/LnVMdT5Lfl0xl0Z +XUM5rIGjLBuREzLC01ZfNU4TdMpja02tCiDFmVraplyyEM7Pyh2uSo2d9FEpw== Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=JbHX7bSe; dmarc=pass (policy=none) header.from=gmail.com; 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" X-Migadu-Scanner: scn0.migadu.com X-Migadu-Spam-Score: -6.46 X-Spam-Score: -6.46 X-Migadu-Queue-Id: DA179B588 X-TUID: CFHqaYERxJC1 Hello, Bruno Victal writes: > Forwarded from: & [1] > > apteryx: IMO the spacing between the fields should have been kept > it makes things easier to read > it's a nightmare if the records grow very large > mirai: I was on the fence about it, but keeping the fields together in the same record appears to be the more conventional style in the code base > (together as in without blank lines in-between) > apteryx: I'm planning to gradually shift the define-configurations to have a space between fields > mirai: it should be discussed first to guix-devel :-) > > > > I'd like to propose for field specifications in define-configuration to be separated with a > blank line between them. Reason for this is that it makes it much easier on the eyes > to read, rather than being presented with a dense hunk of text to sift through. > > I tend to always insert these blank lines when making changes in these parts to aid reading, > even if they weren't originally present and were not planned to be committed. I'd be happy if > I could simply keep the line separations and avoid the tedious insert-erase ritual. > > I think I'm not alone in this opinion, consider the following snippets: > > > With a line separating each field: (gnu/services/mcron.scm) > > (define-configuration/no-serialization mcron-configuration > (mcron > (file-like mcron) > "The mcron package to use.") > > (jobs > (list-of-gexps '()) > "This is a list of gexps (@pxref{G-Expressions}), where each gexp > corresponds to an mcron job specification (@pxref{Syntax, mcron job > specifications,, mcron, GNU@tie{}mcron}).") > > (log? > (boolean #t) > "Log messages to standard output.") > > (log-file > (string "/var/log/mcron.log") > "Log file location.") > > (log-format > (string "~1@*~a ~a: ~a~%") > "@code{(ice-9 format)} format string for log messages. The default value > produces messages like @samp{@var{pid} @var{name}: @var{message}} > (@pxref{Invoking mcron, Invoking,, mcron, GNU@tie{}mcron}). > Each message is also prefixed by a timestamp by GNU Shepherd.") > > (date-format > maybe-string > "@code{(srfi srfi-19)} format string for date.")) > > > > Lines collapsed: (gnu/services/linux.scm) > > (define-configuration fstrim-configuration > (package > (file-like util-linux) > "The package providing the @command{fstrim} command." > empty-serializer) > (schedule > (mcron-time "0 0 * * 0") > "Schedule for launching @command{fstrim}. This can be a procedure, a list > or a string. For additional information, see @ref{Guile Syntax,, > Job specification, mcron, the mcron manual}. By default this is set to run > weekly on Sunday at 00:00." > empty-serializer) > ;; The following are fstrim-related options. > (listed-in > (maybe-list-of-strings '("/etc/fstab" "/proc/self/mountinfo")) > ;; Note: documentation sourced from the fstrim manpage. > "List of files in fstab or kernel mountinfo format. All missing or > empty files are silently ignored. The evaluation of the list @emph{stops} > after the first non-empty file. File systems with @code{X-fstrim.notrim} mount > option in fstab are skipped.") > (verbose? > (boolean #t) > "Verbose execution.") > (quiet-unsupported? > (boolean #t) > "Suppress error messages if trim operation (ioctl) is unsupported.") > (extra-arguments > maybe-list-of-strings > "Extra options to append to @command{fstrim} (run @samp{man fstrim} for > more information)." > (lambda (_ value) > (if (maybe-value-set? value) > value '()))) I have some apprehension that if we start adding white space between the fields here, we'll soon have people adding white space to many other places (for consistency or other reasons), which I wouldn't welcome (I value compactness, and since in Scheme a single newline is used to delimit things at the top level, too much of white space can make things less readable in my opinion). -- Thanks, Maxim