From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id +PsyH9XOwWVEEwAAqHPOHw:P1 (envelope-from ) for ; Tue, 06 Feb 2024 07:16:53 +0100 Received: from aspmx1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id +PsyH9XOwWVEEwAAqHPOHw (envelope-from ) for ; Tue, 06 Feb 2024 07:16:53 +0100 X-Envelope-To: larch@yhetil.org 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=1707200213; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to: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=1nzECTMR1UfAU/crD6zDjGs0NAp6bHp6Bix4hL0ET8I=; b=jV0B1RkdmMwtkfeZ7Upnir5kviIMiklb4OoLVWLb0Mp9tVn+jdn05GNTRJvp7ptzEVVd6/ JZZdtwImRAqJrvKG1rJc3dO9Ab3EHnzeiRll0devtr2r8DrOy3pqi/PABjV69XVg7WvUif YVQzE6c/j0D+0fppj8bMsUUyVcaFCzQd6lbStTcBelzEfBM1hm9xfOCUb1b+QahqhP0Ilw 6mECO3cfUy23WWrw1w4J3tWlOnbGGhS780+nLPBm/YXBZaplwD10ffrJXlVvYfBs1d2tYt 16H0zV0buI3eXyDONWa3sQSx/fe1t4vF+pNG4DmgcL0GIJOlIAbmkjwnvjA4JQ== 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 ARC-Seal: i=1; s=key1; d=yhetil.org; t=1707200213; a=rsa-sha256; cv=none; b=On5QBWVv8qMnpC8lT1bJTDKZHR0NynGyCT4MQmY/y4Ysw3I4MXTYMV62edttP9aCGut7NE iuC3pf4C7RCcqIfQF6NNadPFovP/euDflN07RygcEJUI5VIWuP8JCw08fSmMP8sj7wgWs7 WSbpNIxB/lWYjriX/W7uOfvoNHXtF64f9H7nORIJQCW2hGKuJxDlAFY/Obo17yjb/aPeqJ Mm+HG6TjqXamCPdJdqgMCexpjW1ig0CXVxY2IltqDI5gPb3UUXuIeyw3+tNY+1883X+ubi /0cAg9i/VRhz8f7eZbh++U19YqeySh+27F1heb1uLGwGz9EvDCehjLzKEPd15Q== 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 2DA9A15249 for ; Tue, 6 Feb 2024 07:16:53 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rXEkp-0002NJ-8K; Tue, 06 Feb 2024 01:16:23 -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 1rXEko-0002NA-Fp for guix-devel@gnu.org; Tue, 06 Feb 2024 01:16:22 -0500 Received: from [195.15.247.228] (helo=rdmp.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rXEkn-0003o7-0R for guix-devel@gnu.org; Tue, 06 Feb 2024 01:16:22 -0500 Received: from [127.0.0.1] (helo=[IPv6:::1]) by rdmp.org with esmtp (Exim 4.96.1) (envelope-from ) id 1rXEJJ-0002C7-0Y for guix-devel@gnu.org; Tue, 06 Feb 2024 05:47:57 +0000 Message-ID: Subject: Intermediate abstraction of system service configuration From: Dale Mellor To: guix-devel Date: Tue, 06 Feb 2024 05:47:56 +0000 Organization: DM Bespoke Computer Solutions Ltd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4 MIME-Version: 1.0 X-Host-Lookup-Failed: Reverse DNS lookup failed for 195.15.247.228 (failed) Received-SPF: softfail client-ip=195.15.247.228; envelope-from=no-reply@rdmp.org; helo=rdmp.org X-Spam_score_int: 3 X-Spam_score: 0.3 X-Spam_bar: / X-Spam_report: (0.3 / 5.0 requ) BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_SOFTFAIL=0.732, SPF_SOFTFAIL=0.665, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no 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: , Reply-To: guix-devel-0brg6a@rdmp.org 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-Migadu-Spam-Score: -6.66 X-Migadu-Scanner: mx13.migadu.com X-Spam-Score: -6.66 X-Migadu-Queue-Id: 2DA9A15249 X-TUID: cifwee/dDlXt Hello, I am in the process of moving my production machine to a pure Guix setup, and feeling some pain which I feel is somewhat unnecessary. There are two extremes supported by the Guix system in configuring services: either a native application configuration file is given and used verbatim, without Guix really understanding what is happening, or else a huge pile of scheme code can be constructed which resembles the configuration file structurally and is eventually translated into an actual configuration file. The benefit of the former approach is that all of the configuration options of the application are available and that the package importer has no work to do to support the configuration (in writing translators), but the disadvantage is that this cannot be introspected or (easily) manipulated by the Guix system (for example if another application needs to make modifications so that they can work harmoniously together). The advantage of the latter approach is that the configuration can be more dynamically constructed, but the disadvantage is that configuration is restricted to those aspects which the package importers have gone to (a lot of trouble) to implement, and for which they have to diligently track changes in application configuration specification across versions of the application. The two packages which immediately come to mind which show this extreme dichotomy well are /nginx/ and /dovecot/; the manual pages for those packages show reams of configuration clauses available in the Guix system configuration file (neither of which are exhaustive, ouch!), and they both also allow a single native configuration file to be used verbatim. There is no middle ground. I think that Guix taking the view of a configuration file as a nested set of string-named blocks containing lists of string-named, string-valued pairs would be an intermediate level of abstraction more suited to the Guix system configuration view of the world. It has the advantage that it is introspectible and programmatically modifiable, yet is flexible enough that the full configurability of services is available, and I /think/ it is sufficiently general that it would cover all cases of application configurations. It means that application configuration can be handled more uniformly across applications by the Guix system, and importers of applications have a much easier time coding up the configuration file translator, which would be relatively trivial in most cases. I also believe it would make life easier for people configuring systems for themselves, especially where they wish to deviate from 'standard' setups, which is where I met with most pain. So shoot me down :) Dale