From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:403:478a::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id +EX4CtzXN2W1hQAAG6o9tA:P1 (envelope-from ) for ; Tue, 24 Oct 2023 16:42:36 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:478a::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id +EX4CtzXN2W1hQAAG6o9tA (envelope-from ) for ; Tue, 24 Oct 2023 16:42:36 +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 DD0B2437A1 for ; Tue, 24 Oct 2023 16:42:34 +0200 (CEST) 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=1698158556; h=from:from:sender:sender: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=iyPOmeOl8epr8k3tbqacn3jnhxBxKtV4fOPh/MtFfYA=; b=R6kiDRi0cozgpDwUizgzzPoT//PUQoV5Tu8jNSLUWecidP/LnJD7pD5bPCZKkbJFstfQ8c iRdaC8ac5xtvwNNiL4v7mSfWCPRpT/iKYzIjek99vbzfgt81qVARRqJsCfx3vIskV9PSaw BR36GeWaioc1n9VeNbySLMGoZVt+JEO8IdA7ceVjwZdgmFiUAL6SC4U83wJ2W+QPbLJfg8 727BVCT8B1L+e+DE+oj4jpKZeLIbXtFS2nPKwT61v3COGqljnI7RDRLW0dzNjFd3A2NjMO 59xTXkfkhKBe3qitsVnxm0YrATzVxPcp81qhBI1NZGa4CEr8ipHvu+bSaXJH+A== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1698158556; a=rsa-sha256; cv=none; b=G1+UM8B8WmsPWU3KwnvIFRd/7WA00uHcVNHo9H+zBil/ldFPO3c0u6Gaz4weHT91u5CI6e keVFlD6RJqWSJuBk0Oi5Zpj+RfU3pY98v203EAb79CSLRGPPGTPwGgvrP5fy0iwxiAPU1y xhj1NEsMZUk6h88I7AsQa3XgUEsWXY4TXyGTaf9bl9d5An+tXoDDt1ZzJWCz7tw/AkEDoL aI3+FAmGFprANWazU4ZTsGYZ1ZIqFo7Fd0+7g0EWTHHkpFlSABEsI8yqOhTSAfKxiGDPKh n4KomUqR1NS2twM4+my1f25bbm3/STlp9EC8nk0nReQsGYj7FnIxFlD4qofCpw== 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 1qvIbX-0004Su-IF; Tue, 24 Oct 2023 10:41: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 1qvIbV-0004RS-Cl for guix-devel@gnu.org; Tue, 24 Oct 2023 10:41:57 -0400 Received: from smtpmciv5.myservices.hosting ([185.26.107.241]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qvIbT-0003o4-BT for guix-devel@gnu.org; Tue, 24 Oct 2023 10:41:57 -0400 Received: from mail1.netim.hosting (unknown [185.26.106.173]) by smtpmciv5.myservices.hosting (Postfix) with ESMTP id 0CE8920DD3 for ; Tue, 24 Oct 2023 16:41:52 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail1.netim.hosting (Postfix) with ESMTP id 8035480095; Tue, 24 Oct 2023 16:41:47 +0200 (CEST) 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 dhLFE4Giz61W; Tue, 24 Oct 2023 16:41:47 +0200 (CEST) Received: from guix-nuc (unknown [10.192.1.83]) (Authenticated sender: lumen@makinata.eu) by mail1.netim.hosting (Postfix) with ESMTPSA id 0066B80092; Tue, 24 Oct 2023 16:41:46 +0200 (CEST) From: Bruno Victal To: guix-devel@gnu.org Subject: Divvying up service definitions X-Hashcash: 1:26:231024:guix-devel@gnu.org::mjIFH5mXCG3i5fIs:199zO Date: Tue, 24 Oct 2023 15:41:46 +0100 Message-ID: <878r7skrpx.fsf@makinata.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=185.26.107.241; envelope-from=mirai@makinata.eu; helo=smtpmciv5.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: 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-Flow: FLOW_IN X-Migadu-Country: US X-Spam-Score: -6.11 X-Migadu-Queue-Id: DD0B2437A1 X-Migadu-Scanner: mx0.migadu.com X-Migadu-Spam-Score: -6.11 X-TUID: ElZBd1PsDXPi Hi, As the gnu/services and gnu/home/services grow, I think we should consider divvying the services into stand-alone modules or subdirectories. Consider the =E2=8C=9Cdovecot-service-type=E2=8C=9D in gnu/services/mail.sc= m: as of commit 'd22d2a05c389207f8cdcf824be7738b1499a987c' this service definition is nearly 1600 lines long, with the remainder of the file comprising of four other services with rudimentary support. It becomes troublesome working with such amalgamations as it makes it hard to keep track of the used modules and bindings, especially when define-configuration is used since the serializing procedures might be used by various service definitions. Further complicating things is 'define-maybe', whose use monopolizes the predicate and serializers for a particular service definition. Now, I'm not saying that we should go and split everything into its own module, I'm saying that we should be allowed to split some of them if convenient (all subjective but I believe we can see that working with a monolithic file in the kilolines where the interactions aren't obvious is not fun, and that's without bringing in the hygienic issues surrounding define-configuration and define-maybe). Some considerations (using dovecot-service-type as an example): * Splitting this as gnu/services/mail/dovecot.scm. We preserve the logical grouping of the services (with the addition that, for extremely comprehensive definitions, these can be neatly organized into subdirectories. (same structure seen with gnu/*.scm) A drawback is that 'use-service-modules' might not work with this although I wonder whether 'use-service-modules' & co. provide any value if we are already doing '(use-modules (gnu) =E2=80=A6)' to begin wi= th. They look redundant IMO. * Splitting this as gnu/services/dovecot.scm. We keep it compatible with 'use-service-modules' at the cost of having a multitude of files under gnu/services, without any logical grouping (messy). --=20 Thanks, Bruno.