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 kOx7BztM/GSlWwAAauVa8A:P1 (envelope-from ) for ; Sat, 09 Sep 2023 12:43:07 +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 kOx7BztM/GSlWwAAauVa8A (envelope-from ) for ; Sat, 09 Sep 2023 12:43:07 +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 1AA475FC99 for ; Sat, 9 Sep 2023 12:43:06 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=trop.in header.s=gm1 header.b=aLJMm7rN; 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=1694256186; 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=cFsWrox0G4lxNxBZPYAPSdNdm4iOMKXQIpk9FOAkz3g=; b=BUqABYKyWm7f+S6w5JL25uAlGtVEPqsSykP6uufciyksmTAGZLdEVfcOEyCrpGtseIRwRo GaVdZuQR6mW+1UdDU3TO0roEbZkCYmc6ZOFTWY5P9ZENpBDd/NUWhtTD6hLFw71d6SymV7 6Cnn4NtiokKlf8hGgpz5hPeKPb1718CN7Gvm2yhq/8+9KdrX6sRgrg4USwJwv3YOtIubme m28TjHyvxJOB8fTXVIMOw/NyPvQPzTVQjsRJqncUJbUOV8OUJJ7bzamSr4cPhzv0fD4XXM M1M5XVbXW8lG1TzGgpPGdU9ZJD6nMwDDmsyUai0mUt5LGLigSK+Gk11ro++8Xg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=trop.in header.s=gm1 header.b=aLJMm7rN; 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-Seal: i=1; s=key1; d=yhetil.org; t=1694256186; a=rsa-sha256; cv=none; b=q7IIxiIq/hS2cdZTh4MXaIkBZ6fGxmdM2HXuEMHem0M5Q15JDpfYSuxhONYWI75JmNU5+L 8zs5J9QDNm4e4EW4+k5VE46Ay7dRtOMfZUdE7ui/O+6+VKJA0nEYKJ+RWfYZ3hp4qHL3O9 yR9tRTzrQ2hgm6uzn9um2MXSXC2Tajn9eIvOa28bONRbtfOiTj3452cO3DIuCu5p84qOL0 X27rl6j51XcinLJfUCBPCXgxQyXHLtU4CJgJDYupQHjKUBlypNVAunRwV3i6VIAqGkB/e2 P4DbWItwunGBoQG/lW3RiKHZiYkswY75H6Ze5kjySrtZ3Kb1u/Sfx02JJEQH7A== Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qevQb-0000QY-6F; Sat, 09 Sep 2023 06:43:01 -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 1qevQZ-0000QN-34 for guix-patches@gnu.org; Sat, 09 Sep 2023 06:42:59 -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 1qevQY-0007nJ-RX for guix-patches@gnu.org; Sat, 09 Sep 2023 06:42:58 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qevQb-0003SG-Jx for guix-patches@gnu.org; Sat, 09 Sep 2023 06:43:01 -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: Sat, 09 Sep 2023 10:43:01 +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.169425615313244 (code B ref 65119); Sat, 09 Sep 2023 10:43:01 +0000 Received: (at 65119) by debbugs.gnu.org; 9 Sep 2023 10:42:33 +0000 Received: from localhost ([127.0.0.1]:46229 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qevQ8-0003RX-Sy for submit@debbugs.gnu.org; Sat, 09 Sep 2023 06:42:33 -0400 Received: from relay7-d.mail.gandi.net ([2001:4b98:dc4:8::227]:51025) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qevQ6-0003RI-PV for 65119@debbugs.gnu.org; Sat, 09 Sep 2023 06:42:31 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id DC61F20002; Sat, 9 Sep 2023 10:42:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=trop.in; s=gm1; t=1694256140; 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=cFsWrox0G4lxNxBZPYAPSdNdm4iOMKXQIpk9FOAkz3g=; b=aLJMm7rNk/U5CHu4PDtWolEwOM8fqNYH6/81DLm3Fvu2r98PNoGELAV4sBZHPcRuBbZrx8 X8eE8bNwflBItdtgVow1hopUG92ehqVLsJ/suvKI1mP6nBfhQ/u4aEECEAg5i0Nbigcb4R w3h3vUhYTsxVPtExttYP/F4dO3MGkadjjH1abx1ii4AX0Rz38kMyEe3y5Bw77N4xR5vLmt hFXyiSmmMrL2OvQhQRCIuTPElaJ5GShp4ZkaEjeNGlKf59xWcRdYszifUdBQt0jk28F8Vf 9ZhEuuppsfvm97PCq9ujnO8HQjRqAm6NaIkTTes2kj9S5dxE6zosbKmNnAm5ow== From: Andrew Tropin In-Reply-To: <87wmx0z4u4.fsf@gnu.org> References: <87ttt3a4tm.fsf@envs.net> <87r0nwh5om.fsf@trop.in> <87jztn3uz1.fsf@gnu.org> <87ttsnoct1.fsf@trop.in> <87wmx0z4u4.fsf@gnu.org> Date: Sat, 09 Sep 2023 14:42:12 +0400 Message-ID: <874jk3sk57.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-Queue-Id: 1AA475FC99 X-Migadu-Scanner: mx1.migadu.com X-Migadu-Spam-Score: -1.43 X-Spam-Score: -1.43 X-TUID: +lFHflfDUshW --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2023-09-09 00:18, Ludovic Court=C3=A8s wrote: > Hi Andrew, > > Andrew Tropin skribis: > >> 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. > > I understand what you=E2=80=99re saying. I don=E2=80=99t necessarily agr= ee with all of > it because I believe abstraction is a fundamental part of programming; > abstractions can sometimes be wrong or misleading of course, and that=E2= =80=99s > what we should strive to avoid. > > Back to this patch series, we=E2=80=99ve had one concrete illustration of= a > shortcoming: > > https://issues.guix.gnu.org/65510 > > I=E2=80=99m aware of this and agree it needs to be addressed. > > In assessing this patch series, one should keep in mind that it solves a > longstanding issue with Guix Home (code duplication and the inability to > share service code with Guix System), one for which no other solution > was proposed AFAIK. 1. One of the possible options is to use free-style configurations for services, so we can reuse a lot of code and drastically decrease duplication (only the service definition itself and a one configuration record) and maintanance burden. https://yhetil.org/guix/87ild88kax.fsf@trop.in/ We have only two maintainers and have more than the half of a hundred services in rde, which is not that far from guix itself (258 services). 2. Another option is to rethink service extension mechanism a little bit and maybe make it more polymorphic. https://lists.sr.ht/~abcdw/rde-devel/%3C87sg56g97i.fsf%40trop.in%3E (Just making a rough example of naive implementation) Instead of referencing service by it's value, we could reference its name. This way we can write one service for Home and System, which always extends 'system-accounts-service-type, and for home case provide a different implementation for it, so when we build operating system system-accounts-service-type will add users to /etc/passwd, when we build home-environment system-accounts-service-type will do nothing. Adjusting the logic of the extension based on presence/absence of a particular service can be very useful to make it possible to reuse configuration for Home and System services directly. However, improving service extension mechanism in such way, keeping backward compatibility and upstreaming it is a hard and very time-consuming task. So in rde we just implemented a feature mechanism on top of service extension mechanism to solve challenges mentioned above and it works great. It would be even greater if we could just do the same with plain services. My point here is: let's solve this issue on another level of abstraction, by improving service extension mechanism, not by creating a new level of abstraction (as we did in rde or in this patch series) to cover the wholes in the previous level. I would be glad to cooperate on this and design possible improvements. > My own assessment, having reviewed patches adding Home services (in all > loneliness I must say) is that the outcome is positive, in spite of the > shortcoming mentioned above. > in all loneliness I must say In some previous threads on guix-devel/guix-patches I mentioned, that we will maintain home services for rde separately https://git.sr.ht/~abcdw/rde/tree/master/item/doc/decision-log/0004-rde-fla= vor-guix-services.org and thus all (most of) the home services coming to guix-patches won't be used by rde or me personally. Despite the fact that I would be glad to help with reviews, I already work hard (almost fulltime) on guix, guile and emacs ecosystem in parrallel to running from the war and probably reviewing home services on guix-patches is less valuable use of my time both for me and for the community. > In assessing this patch series, one should keep in mind that it solves a > longstanding issue with Guix Home (code duplication and the inability to > share service code with Guix System), one for which no other solution > was proposed AFAIK. I think that your concern about code duplication is valid (and I'm aware of the issue probably even longer :) ) and I would be glad to cooperate to solve it. However, I'm almost sure that it should be done on service extension mechanism level. If this make sense, we can discuss possible solutions in more details and next practical steps. =2D-=20 Best regards, Andrew Tropin --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEKEGaxlA4dEDH6S/6IgjSCVjB3rAFAmT8TAQACgkQIgjSCVjB 3rCCPBAAlrSdaKKr5Y8jRpnUAjbg280odXuHJ9gnBa+fPLx+SzWo+U3JoHSyoIm+ yOg8Ej5+yMxqXtOonCU2eRXwdIuKFq3qhztvbyo9eJWh7ioQju/sh6HFIV4rlAeo JIaCvqjZFmvPxRKJXdsoAAn9UXn+0/GES483ymJGNKUDR1jbXA/r//RTpQU60VgI N07OTY25fhzj8W4NI5PoxMSbZ+Y2aHYSH6Bf88J+uUaer/tF611C1yKvzez5aeub qXZQmCnEcn7CJzNUlowTVMhC5/mVNlg0PwBR0FNeZtKEm/8w+PHQYaIk+6/DkmxQ HobpWujGADaH7+OdgsWheAQ/RQRwDshvHZNf6vx+x62+PsAhmH8V8CCK/MAfUfc5 FzGA/A81X97cKMxd8Y1MBIcOOx1LrVt0Yl5ILDSC7tfgbah4wvy6lM3P9StDxA3Z yUUT7noIVpek8jwoPDl48eAIbTH0AI5I40ZI2j0ze3QjPmNWf/qEdZ2Fb+bVjCBy vMx+oVSnaqsBO3W10T3kNy3vk5Oc64d7ivD6rZduCV9M/C9XlJu9uE03OosT9gD3 W1kTFuSE4KvVKGm3Gu08pdrFILusIfoMjEPPdYch9XEIVDD5KaFbirpMi0y3ofyZ na9SgMIba2kstjzYJaTnvZKg7UMXcUQrYU/0vIEXu//kCUyJbAM= =xb1u -----END PGP SIGNATURE----- --=-=-=--