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 AMPONr7HHWTsFQAASxT56A (envelope-from ) for ; Fri, 24 Mar 2023 16:54:38 +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 CHaqNr7HHWRCeQEAauVa8A (envelope-from ) for ; Fri, 24 Mar 2023 16:54:38 +0100 Received: from lists.gnu.org (unknown [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 B07FB26472 for ; Fri, 24 Mar 2023 16:54:37 +0100 (CET) Authentication-Results: aspmx1.migadu.com; dkim=none; 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=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1679673277; 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: content-transfer-encoding:content-transfer-encoding:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=BOPF9K+jg/sSP7wDIU4gnjg9M9mhGZq2TOmI3KXpkHs=; b=sVnzDyUjKEi3HnmLsgxjeNlN5lgaY+C/z0WSDVT5HNys3XCGyzb2e8x2qO3eXW1EI3qcic Y+sjcNpYSFYvJxk8e1SGznytuLxU/VDOibZAKbHJ6SASAS/K+/FwQBCBCGZ7KCMbW7xHJZ uIYpd3G3ytuxGNbrnX3zkbUmK1YqFOlKPn4Vvo7RKl31hq0sbXZq2hUrc7liLbqqsc1c6J QpaNYqoCslG7ukr7zksryguNoqtRaPMa4LqLpgoL9kdKep9wRYB5Cm1CQYnUQRZov05ps4 Nq/cmnygTek8zELO7cEhPZsDmGOWWnSi7kMZufDQH8Vuh5JT0ealGt67xVgfYg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1679673277; a=rsa-sha256; cv=none; b=qlppbrsKFNvUlGynpvgfnbUQ12hUCkzkKalt/H6NODZOIV7y+cDk0/kd+G0uKapbSnD5sA Rg+lcOhHgk1Ki8//Vauo5fr3lZ0SdibFMM0jjf3n0D9hJ3bt1Yd/BShgGdbcOSei7XY2y8 Bwx+Lg8YJKLzM8RYpFppgVIJ6X7wG5CjRPhUY3ws8L2oCWefuDEePECgw0nyOvb+LX4FMk 8v8Mu4FCkyKbnQiGifMOW5H9+sQQIB1nBUWlgil+nsLlAIuSF7TgNfAM6qp2BiHK4PiYir Rdp7D1qfkraf3zs8eeAKmJVnGSbRi+IhcNx8NLcfR+3QqGPQBvRg7zG6M2B1LQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; 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=none Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pfgdf-0004Cx-Cg; Fri, 24 Mar 2023 08:35:25 -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 1pfgdb-0004Cb-Ap for guix-devel@gnu.org; Fri, 24 Mar 2023 08:35:19 -0400 Received: from smtpm2.myservices.hosting ([185.26.105.233]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pfgd5-00009m-4I for guix-devel@gnu.org; Fri, 24 Mar 2023 08:35:17 -0400 Received: from mail1.netim.hosting (unknown [185.26.106.173]) by smtpm2.myservices.hosting (Postfix) with ESMTP id E7A0820F40; Fri, 24 Mar 2023 13:33:57 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail1.netim.hosting (Postfix) with ESMTP id 84A6F800AB; Fri, 24 Mar 2023 13:33:57 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mail1.netim.hosting Received: from mail1.netim.hosting ([127.0.0.1]) by localhost (mail1-2.netim.hosting [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id SPg8hniUsVxq; Fri, 24 Mar 2023 13:33:47 +0100 (CET) Received: from [192.168.1.239] (unknown [10.192.1.83]) (Authenticated sender: lumen@makinata.eu) by mail1.netim.hosting (Postfix) with ESMTPSA id 74DC7800A9; Fri, 24 Mar 2023 13:33:47 +0100 (CET) Message-ID: Date: Fri, 24 Mar 2023 12:33:47 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 X-Mozilla-News-Host: news://news.yhetil.org:119 Content-Language: en-US Cc: mirai , Maxim Cournoyer From: Bruno Victal To: guix-devel Subject: [RFC] Cosmetic changes to define-configuration usage Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=185.26.105.233; envelope-from=mirai@makinata.eu; helo=smtpm2.myservices.hosting X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, 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-Queue-Id: B07FB26472 X-Spam-Score: -2.34 X-Migadu-Spam-Score: -2.34 X-Migadu-Scanner: scn0.migadu.com 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 X-TUID: CM22FetP3z4S Forwarded from: & [1] --8<---------------cut here---------------start------------->8--- 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 :-) --8<---------------cut here---------------end--------------->8--- 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) --8<---------------cut here---------------start------------->8--- (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.")) --8<---------------cut here---------------end--------------->8--- Lines collapsed: (gnu/services/linux.scm) --8<---------------cut here---------------start------------->8--- (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 '()))) --8<---------------cut here---------------end--------------->8--- IMO, the top snippet looks much less overwhelming than the bottom one. ## “Implementation” plan This cosmetic change can be done gradually or with a commit that performs the restyling in bulk. [1]: Cheers, Bruno