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 ms9.migadu.com with LMTPS id UDVGGz4X+2QmCQEAG6o9tA:P1 (envelope-from ) for ; Fri, 08 Sep 2023 14:44:46 +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 UDVGGz4X+2QmCQEAG6o9tA (envelope-from ) for ; Fri, 08 Sep 2023 14:44:46 +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 13755470EE for ; Fri, 8 Sep 2023 14:44:46 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=trop.in header.s=gm1 header.b=IQmo7Xs4; 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=1694177086; 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=NmmXn+673iB4ccnX95P/pDYLI5Ej4xaIpQZhFssbCy4=; b=NJTjbNm/NY8DOWpFZ3v+Vaq44VRnYL1wCIl4fsyq0etX44kjVcmxZed3SEtouE8moFR4jt uPCcHTyWkH91EsmYhDbS6Gcy4Pqs4+4M20pwgmpgnQaS0AWGHUGxOFMaF5KjXZzIIRy3gQ qGki1uGcFxVqNUkDePnA2MC32v/ntAahOdmxG9vMQzXdxpUZ85xVTYI5/XQ1rvC1kaB91X X0merFOHabwfzjRP6W+Dn4+oCvvG3AID+4Vl0KdTjrsP5mrsDxqKbDXhskllpgSF00f/ET 25YNNxeW+UoqZtzBais3qlnEb+YmBYTTpLMYdFS+p5eg7Hxi9yr8G6O9x+a1zA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1694177086; a=rsa-sha256; cv=none; b=fEnTiP/HuAa8r/yhiCJKjPXHrcd3kTtN5ahjQjvyUUs9UxaUWrdWG4rtP/2/1IVqbf8goC l39w/Z4p+pRuN7nYKXGL3ZX41f+O96EpekcVFNzlO9QIt3P7pt7Ed8pzI34vB3ksa1Y7xY rQ4+mM41eDmI7pbY9tJCd7O1gL7T7BPsuLDXgATP4jmFcwC+oN16ASJcxInnc3P83PJltR x88rVjXAUmD4XV6AlJAiowDCVz/H/Djk2c2Txr+rhBBikBS2m/u+c2p8Bei5oMJ1X2tsnW /oeXfPx1+nbcKJvP096tZVZvS//vcjhynri4FOp3+C1dg1FizyFEp2PbR6k+Nw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=trop.in header.s=gm1 header.b=IQmo7Xs4; 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 1qeaql-0002Iw-Hv; Fri, 08 Sep 2023 08:44:39 -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 1qeaqP-00029w-JA for guix-patches@gnu.org; Fri, 08 Sep 2023 08:44:21 -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 1qeaq9-0005qD-1z for guix-patches@gnu.org; Fri, 08 Sep 2023 08:44:03 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qeaqB-0003nv-7B for guix-patches@gnu.org; Fri, 08 Sep 2023 08:44:03 -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, 08 Sep 2023 12:44:03 +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.169417698714500 (code B ref 65119); Fri, 08 Sep 2023 12:44:03 +0000 Received: (at 65119) by debbugs.gnu.org; 8 Sep 2023 12:43:07 +0000 Received: from localhost ([127.0.0.1]:42518 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qeapG-0003ln-8B for submit@debbugs.gnu.org; Fri, 08 Sep 2023 08:43:06 -0400 Received: from relay8-d.mail.gandi.net ([2001:4b98:dc4:8::228]:42055) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qeapC-0003lH-SR for 65119@debbugs.gnu.org; Fri, 08 Sep 2023 08:43:04 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id 561D31BF20A; Fri, 8 Sep 2023 12:42:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=trop.in; s=gm1; t=1694176974; 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=NmmXn+673iB4ccnX95P/pDYLI5Ej4xaIpQZhFssbCy4=; b=IQmo7Xs4mv+auPyOfE/WeYW8iplNlIOb7uvgeaI5i6bpx/EGiJsYLbclFvdNGM82Etu7kt BFcLWeJjYx8shC/ONHDBe9D6TIcVSBYq8sZXQd+SDMEbggSX4Irvhxp41X+m7W/c0oSchw uu9q+aMc5ZgeD6Kvh2AMbRe8xp8rNlFDU5Q8FeJLUe77RYvmOKinovZ+cV6QG8HMB7yJUh i3hPv2smvcUtJqV6cBe57DQ3MOC++huJhEvbtNDqXbZDRKVV+ecyd130MS7Yp5/s8rlhcu vLQCzLfv0OmACbcnn02VffEvNElMW4Y72JxmBIcuWqS9hJZ713G6WvUkWvnEIQ== From: Andrew Tropin In-Reply-To: <87ttsnoct1.fsf@trop.in> References: <87ttt3a4tm.fsf@envs.net> <87r0nwh5om.fsf@trop.in> <87jztn3uz1.fsf@gnu.org> <87ttsnoct1.fsf@trop.in> Date: Fri, 08 Sep 2023 16:42:48 +0400 Message-ID: <87bkec6dkn.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-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Scanner: mx0.migadu.com X-Migadu-Spam-Score: -2.61 X-Spam-Score: -2.61 X-Migadu-Queue-Id: 13755470EE X-TUID: Fw8UZ0fyGv1r --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2023-08-25 10:28, Andrew Tropin wrote: > 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 fr= om: >> >> (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> To support my previous suggestion to revert this patch series I will document the example of a consequence: https://git.savannah.gnu.org/cgit/guix.git/commit/?h=3Dcf6abf50dbbbd95fef46= 5ab4bb3b608843ac47e1 https://issues.guix.gnu.org/65510 It highlights this: > Now the result of evaluation depends on the order source files are > read. >>> Collecting those values in unknown order and applying this >>> implicit transformation making a good room for foot shooting. to say it differently this change introduced the implicit dependency on the fact of the evaluation of the form, which is not explicitly referenced anywhere. > 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: = macros and >> records are part of the Schemer=E2=80=99s toolbox, we try and use them w= isely, >> 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/6IgjSCVjB3rAFAmT7FsgACgkQIgjSCVjB 3rCkfA//aS+LyB4R5/jKJSXqPRm4HHRJC/zBbDT5cPowyLRX2ymVQZoYwqCIeDxx 4NnVOYLrjjTe7UwOg+QIcMDpyhFNcOIJt8UvyI5NCpkwLyzHx7+2lvJq9WBuBM0y qDfOkWCoI8ywPrDpz+ajjUoYxE/cmg3IjhECmU/RacHqzGFZry6EG0PD6txpX7Yi l/sdaISnvVkLllvvaZGASgNQ7huwmLpNGCW0hNDzu2+GdVM0LI2kJCyAQG+PvXu8 avRQI0pfvvOdIeps70b4pv34yxylBA+ZuxphGmk8lUmWI5vRWHBF3WCcw3v6hnCc T3pqRofxXNgrHhyaEqQ3VPCNXT04bfN4hl2vJmyX+M8E+7Zq9My+BQh0sHZVK2JE Ui/Mtx5vzmSPxFqjwbgG5UfJfpWA9zuJIpikDHVf4sYVkhQOrK0o9cRULg9ppAuE aVc21kyRvA3gDBnEWrp754rY7dJ4JNzWHNVrbxKgx/O4rV0HChGpxjyLkBwI6r5C HMbDuRqI5jns2MmGwGrRbbFDuNkX6hDSFLDQPi7/AXJoipJ8sIVR06wT01nl9eCM ZDGE13hS9obZCNmyDIdKh0bbeFVsWMccMgpuiqVzlg1+RR7k6oiBs/E1uiULUZn8 BUn7xLfwdxvpcfUbHbF93jIJ7I6XEMW41cJMDvYVJj+1TOHqRJI= =i2uj -----END PGP SIGNATURE----- --=-=-=--