From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:403:4789::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id cPEEHJJK6GQ77gAASxT56A (envelope-from ) for ; Fri, 25 Aug 2023 08:30:42 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:4789::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id CBX0G5JK6GSWugAAauVa8A (envelope-from ) for ; Fri, 25 Aug 2023 08:30:42 +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 4ED1C5ABB4 for ; Fri, 25 Aug 2023 08:30:41 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=trop.in header.s=gm1 header.b=R5NgiPII; spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-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=1692945042; 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:resent-cc:resent-from:resent-sender: resent-message-id:in-reply-to:in-reply-to:references:references: list-id:list-help:list-unsubscribe:list-subscribe:list-post: dkim-signature; bh=7GZIJFKoz/P5QdwJCespvgwo7Z5kXVMTH2pYxW8AfJ0=; b=HkRd/itzw/NuufSXKX4kyO/U/MOSLz0u6ZpICum3BHpTpYquGxblMlE6huaB+XU29syUdn q1BUXUol2TaiPDA2fWF4aMt3d3SlVMZuJq3eWWpdEP0oJgzNXezSkpunCXEk9EqBN+SKcj d7Ow6fB6F5QlmxoOQqUsH6yROF+fxLt9T1qTmPapF+5A3PhI1GAJc0UJ2O0te/C8avdjSZ lcb7XTOkXwhAXjPlklyRws0E+9xbwY402R1m2PrqBN42WxT9EJhwzi9LnPzpXq8rpXFf4X HsezVtT9sn/Qp2rzFpcw00fijvotvd3rRJ/EHY0OjbrGZUx3No9z4/xN3yLmwg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1692945042; a=rsa-sha256; cv=none; b=AXRhpNNwKy2rOWu9nX+DRacXCHGD1fdxbswyyY/cZfTxi1VUiJ+k+lE84necmmwpbMp6AW AGpCI/Pkzzt35oEc1PvSTeHrQ3Ift/JVWhjaN+AWnZeJRinm1I+Ft7JOnYVkXY1Ac04XLi tFIYJA6FPgmK1g0b09tCGi2F/FoRo4U+8xnNocKXyf8ELcgImTPinn40jeAHLBJdWBo7OT tlYIwP28BWGOAf3/M8B2zf/PkwFMYhG97fgwm4J2v6MWrCrIf4bExZPIOn53JPMG6pkvtd yNKW6gInuPCwn7pteFrchiN82F3Wcdl8PNiRrXfFvXVTZbzWvMr+Ne6Pj9rB6Q== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=trop.in header.s=gm1 header.b=R5NgiPII; spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-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 1qZQKu-0000jE-5d; Fri, 25 Aug 2023 02:30:24 -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 1qZQKU-0000fg-8G for guix-patches@gnu.org; Fri, 25 Aug 2023 02:30:00 -0400 Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qZQKT-0002GB-US for guix-patches@gnu.org; Fri, 25 Aug 2023 02:29:57 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qZQKY-0003MG-9X for guix-patches@gnu.org; Fri, 25 Aug 2023 02:30:02 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#65119] [PATCH 0/8] Sharing service code between Home and System Resent-From: Andrew Tropin Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Fri, 25 Aug 2023 06:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65119 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 65119@debbugs.gnu.org, =?UTF-8?Q?=E5=AE=8B=E6=96=87=E6=AD=A6?= , paren@disroot.org Received: via spool by 65119-submit@debbugs.gnu.org id=B65119.169294495712817 (code B ref 65119); Fri, 25 Aug 2023 06:30:02 +0000 Received: (at 65119) by debbugs.gnu.org; 25 Aug 2023 06:29:17 +0000 Received: from localhost ([127.0.0.1]:39029 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qZQJo-0003Ke-IT for submit@debbugs.gnu.org; Fri, 25 Aug 2023 02:29:17 -0400 Received: from relay3-d.mail.gandi.net ([217.70.183.195]:51041) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qZQJn-0003KP-8z for 65119@debbugs.gnu.org; Fri, 25 Aug 2023 02:29:16 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id 3B14660002; Fri, 25 Aug 2023 06:29:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=trop.in; s=gm1; t=1692944944; h=from:from: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; bh=7GZIJFKoz/P5QdwJCespvgwo7Z5kXVMTH2pYxW8AfJ0=; b=R5NgiPIIpBxF1lnR6KmIJY4BFjFdbR1a1A6GJwijtKA7uLRjwHPbdF3D4zcELt0l37GFRj oQtrpLgQJODMPioG2pkFhrdDPvou3Ed2HMo96d6SbznNIuIpwKlfFwQ9cMw16oMTXMQ2/T 7xRERImN4vRZbGVu3sdIIzFCBHoaa8ul6sjRWmo5hxJsoO1Gp59Gdub4BlzFECFCiGgsIZ Op7FJFL/bh2pvDvQTIc1TbxMdKDDwaSM+JYQxtCb34xYMN5qDNO3V47KyrvhC832i6FzKN Hj66ucOvzDsfIXhQDffxMDLwYv+3/G4iokqHwm8JYTpc/CmVwG0mnIt6I8FwHw== From: Andrew Tropin In-Reply-To: <87jztn3uz1.fsf@gnu.org> References: <87ttt3a4tm.fsf@envs.net> <87r0nwh5om.fsf@trop.in> <87jztn3uz1.fsf@gnu.org> Date: Fri, 25 Aug 2023 10:28:58 +0400 Message-ID: <87ttsnoct1.fsf@trop.in> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-GND-Sasl: andrew@trop.in X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: guix-patches-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -7.41 X-Spam-Score: -7.41 X-Migadu-Queue-Id: 4ED1C5ABB4 X-Migadu-Scanner: mx1.migadu.com X-TUID: qwtNJj4A07Oq --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2023-08-22 18:25, Ludovic Court=C3=A8s wrote: > Hi Andrew, > > Andrew Tropin skribis: > >> Sorry for comming late to the party, I saw this message only a week ago >> and didn't have time to make an extensive reply yet, so I will share my >> quick thought on the most problematic part and maybe later will >> formulate others thoughts in more details. >> >> define-service-type-mapping looks imperative and potentially very >> problematic. Collecting those values in unknown order and applying this >> implicit transformation making a good room for foot shooting. Imagine >> someone would like to use his own (let's say) shepherd home service >> implementation and will add this to one of the source files of their >> channel: >> >> (define-service-type-mapping >> shepherd-root-service-type =3D> my-home-shepherd-service-type) >> >> What happens if somebody will use his channel just for getting some >> package? Very likely it would break the build or in the worst case it >> will build with unexpected service implementation under the hood. > > Yes, this is always possible. Though it=E2=80=99s not very different fro= m: > > (set! home-shepherd-service-type =E2=80=A6) Yes, and and this is exactly what this solution does and in addition to that it hides it under the sweet define-service-type-mapping interface. `set!` explicitly communicates the danger of usage, define-service-type-mapping does not. 1. We introduce a global state here and infect potentially all the modules from all channels with it + mask it with nice interface. =3D> Now the result of evaluation depends on the order source files are read. Every channel can break valid user's configurations with perfectly legal public guix API. We make reloading of the modules and REPL-driven development in general a huge pain in the lower back. 2. The service extension mechanism is already quite complex to understand on its own, in addition to that the devirsity of record creation macros / DSLs (define-record-type, define-record-type*, define-configuration) doesn't make the situation better. We introduce one more DSL on top of couple existing. =3D> Learning curve raises even higher. Inspecting, navigating and debugging such code becomes harder. It prevents future extension with for-container or for-development-environment. It saves couple of lines and avoids some minor repetions at the moment, but not sure that it's the right way to reuse the stuff between home and system services. > > Maybe the unintended effect is more likely to happen unwillingly though, > maybe. > > Do you have other solutions in mind, be it for this specific issue or > for system/home service mapping in general? > >> I had [1][2] and still have concerns about macros and records >> composability and reusability. I personally don't like excessive usage >> of them in general. By adding more macros, already quite complex guix >> services mechanism becomes even more harder to learn, inspect, reason >> about and work with. In addition to that it has a major technical issue >> mentioned above. I'm strongly against this change and would suggest to >> revert it. >> >> I hope it doesn't sound rude and I'm really thankful for your work on >> this, but I just think it's not the right solution, at least yet, in its >> current form. > > It does sound a bit rude. :-) I would have loved to get any feedback > from you while we were discussing this in the course of reviewing the > Syncthing and Dicod patches a couple of months ago (which I believe you > were Cc=E2=80=99d on, as member of the Home team). > > I won=E2=80=99t argue about macros and records, it=E2=80=99s off-topic: m= acros and > records are part of the Schemer=E2=80=99s toolbox, we try and use them wi= sely, > and Guix code has always used macros and records. We can discuss > whether a specific macro or record type is suitable, of course, but > general statements about them are unhelpful. > Actually, it's quite on-topic IMO and it seems as a consequence of the abandoned discussions I linked earlier, but it's a long story and we can keep it aside for now, because despite the reasons lead to this solution it has fundamental problems on its own we better to focus on. Maybe later I'll elaborate on my thought process in more details. > Was it =E2=80=98for-home=E2=80=99 that triggered your comment? > > The patches do not introduce any new record type IIRC; what triggered > your comment regarding records? > > I=E2=80=99m all for making changes to improve on this patch series. I=E2= =80=99m against > reverting the patch series: the conditions for reverting are not met > (info "(guix) Commit Access"). > > Thanks for your feedback, > Ludo=E2=80=99. Please treat it with adjustment to my not very proficient level of english and lacking ability to express nuances. It's not a personal critique in any way, it's my roughly formulated concerns on 1. technical aspects of the solution and 2. possible consequences for the future of guix and its user-facing API. =2D-=20 Best regards, Andrew Tropin --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEKEGaxlA4dEDH6S/6IgjSCVjB3rAFAmToSioACgkQIgjSCVjB 3rDAnw/+MfkFcHw/XcTyD20CxMWnibpV/l2hWvFkvsMyvZ0cBfbR4Z5JXYJFsmZp Etj9PjEUGIMfDmL5h3QXnMKss20eW7/reTqj1h0JvWdRbjkCtNBp0xGwwe2SV3TF OsLIiy3ww8oALvsaF4n1FkBOqwjgQsh1IQKlqqIfIfI5Xzb103nIGKJYROnqnKe7 zyd4l8KgQXQYNvucoQ3bVtWSZ8/Oc3VfiMpdfHx7dpcD1RajvmzNrFOQ881/Nxmj gu61diI7zN21MkceaK52yvJ30s23tZ6Em11C8/i8ziqsDMIAIDRYQG47fgAx5tXC sW644guJqxM01CYI4KY/99IGQAblDU9C77LxnkOGP+7vq35AF/NHUuUpJyBP76GU icXsKoDK1QJhj/qDoQlYDR6cY0jkM0WqpUIMnwH5P8MVcowRtt1uq6F1umeELdMc ZBlx38fbGP5MKuloVPEhpF5sqVPRiw7Ym3GMwL/oH5ZwkFikPRucTjN9uqkYMO5F ujlGYncUTXYcw4OetSdLNX74tI5M31DL7NaraQxOUz3GtRkk7/zZ9jgUO5V4Rghs NZ3st9YNOhECyBw4SgOSF4iBJNi4BoUwVKPBRjcB74Jy4ZMMo0fOXGL1NfH25Vb+ n9o19bhFjm7F11F+pg+9A1y02OKffCGYZYPILTV1viT1erJY1zw= =wC/3 -----END PGP SIGNATURE----- --=-=-=--