From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.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 AOJpBHVeSmU0pAAA9RJhRA:P1 (envelope-from ) for ; Tue, 07 Nov 2023 16:57:41 +0100 Received: from aspmx1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id AOJpBHVeSmU0pAAA9RJhRA (envelope-from ) for ; Tue, 07 Nov 2023 16:57:41 +0100 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 6D8FF11A27 for ; Tue, 7 Nov 2023 16:56:56 +0100 (CET) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="SHpCnx/a"; 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=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1699372616; 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: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=PGM3S3fMag6psfbBEPYbhBhHnrsfz2IX4sAz3dK/Xcw=; b=n6Zzjqodo0Lek5fZ91S95Di5NkPQPzwFzt1GEIAQlSznIW6ojPnrirAG4Y/roAsHXOtT24 bHJjB640MmG7YAj4yItSsF9ia/4DldUoyDgUH8rcEwwU+9XTnhW5h9ebBaQt8jMJm+wUsQ TrACAMv08i8o+Quuzaz/x6cF/T3JeaBgQSVhs9Zc2y/iBzJsuJBlJmgrNYkA/LkPVwhZFJ Dot5l4OS+wn8Ca23kyb19GPyGU96NOhxTd2kwxHcyDhXQx9/uXvIGcx/GPx37m71xUr+ZA eesLMhdxVD7LrbmDAGQTucRTDA6gA+zPFF9qVfo/sBFDEembK52ZBOF/pK6adg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="SHpCnx/a"; 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=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=key1; d=yhetil.org; t=1699372616; a=rsa-sha256; cv=none; b=e32zRyUZWBGCTG8KUs6pIaQCIf8dxJXb6dW9gbe9sMEMuKYd8GAfP4afn5Tv03PFCofLlr wUV8KlRtBzd83k8OoDq/Y45q20ThQinQU7Fsd/l4nS0AYRgxwLgLkqDNXsdcGwLj07Sa4v k/2mR6Ti8eTZaM/2HhkhgmsanZSYMOpDAlPneKQPy1vxaHvK5yFHoRdcpQHA5RsrtKQ5Ee 09egb1RiD5gFA45KLrFRvVK9HyqL2M12KQX8iEGFIRmQQnF4iwvgd4G3KDcmXKgeWKoGYz AzVzXmteTqV69SSv4yAGeiyvnBsJRLpNH+vmIXl+JMr2tORmtv5U07JNkwhn/Q== Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r0OR7-0001Yt-P3; Tue, 07 Nov 2023 10:56:17 -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 1r0OR6-0001Yg-Km for guix-devel@gnu.org; Tue, 07 Nov 2023 10:56:16 -0500 Received: from mail-oi1-x231.google.com ([2607:f8b0:4864:20::231]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r0OR5-00020n-1f for guix-devel@gnu.org; Tue, 07 Nov 2023 10:56:16 -0500 Received: by mail-oi1-x231.google.com with SMTP id 5614622812f47-3b512dd7d5bso4021450b6e.1 for ; Tue, 07 Nov 2023 07:56:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699372573; x=1699977373; darn=gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=PGM3S3fMag6psfbBEPYbhBhHnrsfz2IX4sAz3dK/Xcw=; b=SHpCnx/aQ9qqws0iCwtEzFnpiqmjFlciIZFw17Xwo8wnyBjP9tqOTw9EPpEkJsShfJ j3qGyWK6mEGWUsh5KV42olyYulLMve0blBFQ4p2vok/GsBrV5UTro/dx/v4tT6UxcBqd AnTcIeU45hiAm1ggPhOwZRgieEUJLynsve5GQ5vBBm/9mp0oCChta0A4rhxrVC0ItaI3 uh/jQDSG+mvHVoTXyqrOruBLFJEi2OaNy6e3jV9YELsSeqcmUhKDJIXxs2CU1TdT6M74 Ljb5hvNIw1V7UFqh0saGPYexO9oLc6g9i258Ba2MUEXJW35p7dosrswv5PFtyRjFG2lU 5J9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699372573; x=1699977373; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=PGM3S3fMag6psfbBEPYbhBhHnrsfz2IX4sAz3dK/Xcw=; b=n8RbIJPGbBmI6nCTBKkK+/lGeoiAcvCbjdSjPXXaNeESYg+2z14D8wGFdQIx1DTL6b 22N7Kx1YuVdhSHFRHyohGHP2Q7I8fBWAHJguwvd3BcByEibpb5D1FgRDMbX2NUto1RLa RvNES+ZbJUHr2rMNSPc3w7XPsq+Y8iPNXera3ckBkALZqS69vIFdpYFqLImwt3x59Q7f sdh0wl0vLhvd8BSA0RiZu6/D8bsqCK47bolqtsisj0FoUNHenlY9TLxhK4rxi4yCDD9p G/V4sukEctnWC7c6qatlCv2tNryIMINT+HHpaOowJzV8Zd2gDzmlIEl4s6RdDWnldDO9 eFZw== X-Gm-Message-State: AOJu0Yw76rxGVZMCnOe6jPk0XG6OXlsRW8p6/SOBQp3XE8lULVequWIV gk98zZblIeHpF/NMTIIs8WOrgslIKEw= X-Google-Smtp-Source: AGHT+IFaFGHntI/quV77ka2FXCB2upfwQYiLmMnIw/bR70yUI/sLTsjt29bReXSwfNGIbrkGwL75bg== X-Received: by 2002:a05:6808:4494:b0:3b5:6432:e0eb with SMTP id eq20-20020a056808449400b003b56432e0ebmr27147378oib.38.1699372573417; Tue, 07 Nov 2023 07:56:13 -0800 (PST) Received: from hurd (dsl-10-130-87.b2b2c.ca. [72.10.130.87]) by smtp.gmail.com with ESMTPSA id br36-20020a05620a462400b0076f35d17d06sm13790qkb.69.2023.11.07.07.56.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Nov 2023 07:56:12 -0800 (PST) From: Maxim Cournoyer To: Bruno Victal Cc: guix-devel@gnu.org Subject: Re: Divvying up service definitions In-Reply-To: <878r7skrpx.fsf@makinata.eu> (Bruno Victal's message of "Tue, 24 Oct 2023 15:41:46 +0100") References: <878r7skrpx.fsf@makinata.eu> Date: Tue, 07 Nov 2023 10:56:11 -0500 Message-ID: <87pm0lk15w.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2607:f8b0:4864:20::231; envelope-from=maxim.cournoyer@gmail.com; helo=mail-oi1-x231.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, T_SCC_BODY_TEXT_LINE=-0.01 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-Migadu-Spam-Score: -9.42 X-Spam-Score: -9.42 X-Migadu-Queue-Id: 6D8FF11A27 X-Migadu-Scanner: mx13.migadu.com X-TUID: 5UPCzH4x/arD Hi Bruno, Bruno Victal writes: > 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.= scm: 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 = with. > 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). That's a great initiative! I agree that multiple 'define-configuration' services per file can be a bit messy, having to use prefixes everywhere, making the definitions more verbose. I don't have a strong preference of the caterogization of services, but would perhaps prefer the first one (gnu/services/mail/dovecot.scm), which could then make it easy to offer some interface as gnu/services/mail.scm that'd re-export all that is needed (would that work, or reintroduce the same top-level clashes?). --=20 Thanks, Maxim