From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id 4LJPBHXg5mFSqgAAgWs5BA (envelope-from ) for ; Tue, 18 Jan 2022 16:44:53 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id mC78AHXg5mG6xgAAauVa8A (envelope-from ) for ; Tue, 18 Jan 2022 16:44:53 +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 A0EF53B272 for ; Tue, 18 Jan 2022 16:44:52 +0100 (CET) Received: from localhost ([::1]:47052 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n9qfD-0004xH-TM for larch@yhetil.org; Tue, 18 Jan 2022 10:44:51 -0500 Received: from eggs.gnu.org ([209.51.188.92]:56740) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n9pRI-0007YN-MS for guix-devel@gnu.org; Tue, 18 Jan 2022 09:26:24 -0500 Received: from [2a0c:e300::1] (port=45012 helo=hera.aquilenet.fr) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n9pR9-00074M-BO; Tue, 18 Jan 2022 09:26:19 -0500 Received: from localhost (localhost [127.0.0.1]) by hera.aquilenet.fr (Postfix) with ESMTP id 159497A0; Tue, 18 Jan 2022 15:26:11 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at aquilenet.fr Received: from hera.aquilenet.fr ([127.0.0.1]) by localhost (hera.aquilenet.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EI1h_CRMSJKs; Tue, 18 Jan 2022 15:26:07 +0100 (CET) Received: from ribbon (91-160-117-201.subs.proxad.net [91.160.117.201]) by hera.aquilenet.fr (Postfix) with ESMTPSA id BE5EE2D2; Tue, 18 Jan 2022 15:26:06 +0100 (CET) From: =?utf-8?Q?Ludovic_Court=C3=A8s?= To: Andrew Tropin Subject: Re: Return back original implementation for text-config serialization References: <878rvp1deg.fsf@trop.in> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 29 =?utf-8?Q?Niv=C3=B4se?= an 230 de la =?utf-8?Q?R?= =?utf-8?Q?=C3=A9volution?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-pc-linux-gnu Date: Tue, 18 Jan 2022 15:26:06 +0100 In-Reply-To: <878rvp1deg.fsf@trop.in> (Andrew Tropin's message of "Sun, 09 Jan 2022 12:12:07 +0300") Message-ID: <87mtjtglxd.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: + X-Rspamd-Server: hera X-Rspamd-Queue-Id: 159497A0 X-Spamd-Result: default: False [1.40 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_CC(0.00)[gnu.org,gmail.com,yoctocell.xyz]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_ENVRCPT(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_FIVE(0.00)[5]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; SUSPICIOUS_RECIPS(1.50)[] X-Host-Lookup-Failed: Reverse DNS lookup failed for 2a0c:e300::1 (failed) Received-SPF: softfail client-ip=2a0c:e300::1; envelope-from=ludo@gnu.org; helo=hera.aquilenet.fr X-Spam_score_int: 1 X-Spam_score: 0.1 X-Spam_bar: / X-Spam_report: (0.1 / 5.0 requ) BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665, URI_NOVOWEL=0.5 autolearn=no 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: , Cc: guix-devel@gnu.org, Xinglu Chen , guix-maintainers@gnu.org Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1642520692; 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; bh=cL1hY7xl/SVyovjpOASt96DOC7PHPfqtj6ggF81v3As=; b=ulEuuQnj21RmXdEO4bLZBe67w+8igq6Ai3qE+UoX9oYzSpn438dNQRdcxSIIewpH4tVfeg Ic9N3wZ4dpF03tVJGvSpPme28XTdUqVbAs5xeh4cDnX+I7h772/Zwzj8NA+Hb7iRPGHChv eoZ05yvJyzia4/IkpeAusxlgsBd6lg+N7PV4vvgFtDa8cyqPO2ut8lOPepf8SqD83KJvzP fzQb+LmdrS6xO7eDjPgmL8HSvliTkBKXOHu6poCUAsgZm0vPE8DMAxmF4mkK/IQ+mduVSD J2pKlX369tfkusKRkxXt6BNO3x8kUXM85AT7uwM5oP//5zoctsDmAIfK1vtxuA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1642520692; a=rsa-sha256; cv=none; b=qRg83+3tv82PvXDhjxmyHttRH9WQ1IyO9m4WCXveViS8Kudw0VHilhcIBUg/+ijsK8m/sM Lunh0uqYg3GuEwb4hDvN0AyTHYZQyvPphz9bUkw9RKbOCgdQUG7KPqcTg6oGakY3xDYaXr DuPzwYeB05Mq8/fnTBiMXjwfnlokF+v3rRMdVNkGYOv3lhtHxdL7mHm4RMES4ZlBjHJoTl 11nQP8I18svoEmMUzT7JZu//uID08iB4eB3l55KsnINBRuDZZGLoN5SwOM03SsQqUrQDDj I6ryy/66MopAVnLpadaCJiqTLejqwKkf8ZTK0nRJ4yQ11j4KNL29zMb+riNPpg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=pass (policy=none) header.from=gnu.org; 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" X-Migadu-Spam-Score: -3.62 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=pass (policy=none) header.from=gnu.org; 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" X-Migadu-Queue-Id: A0EF53B272 X-Spam-Score: -3.62 X-Migadu-Scanner: scn1.migadu.com X-TUID: XxbCshqLNuR/ Hi, Andrew Tropin skribis: > During the upstreaming process of Guix Home commit > fee0bced7fec2f9950957976a28f033edd4f877c slipped into master. It > introduces a different serialization approach for text-config from what > was orginally used: > https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services/configuratio= n.scm?h=3D2c451db39aabc69bdbf186f412ee6e0b4e180ccb#n386 > > This new approach is inconisistent with the ideas used in the number of > other home services (not only the ones using text-config): > https://git.sr.ht/~abcdw/rde/tree/47f6c65c82a4f6761fa1ff5b9405b363cfda648= 2/item/gnu/home-services > > So I had to fork it back to avoid an inconsistency and renamed > text-config to gexp-text-config to avoid a confusion with upstreamed > version. > https://git.sr.ht/~abcdw/rde/tree/47f6c65c82a4f6761fa1ff5b9405b363cfda648= 2/item/gnu/home-services-utils.scm#L355 > > Having two serialization approaches stops me from upstreaming the rest > of home services from rde to Guix and also makes a split to rde home > services and guix home services, which I would like to avoid. I=E2=80=99d like to clarify how I think we should work. Guix development happens here, on Guix channels, using the project=E2=80=99s peer review processes. What rde does certainly is inspirational, and that=E2=80=99s what got us Ho= me in the first place; in my view, we may sometimes choose to take ideas from rde in Guix and Guix Home, but rde development alone cannot be used to justify changes. > We need to decide, which approach should be used or we will end up with > two competitive incompatible implementations and unecessary split of > effort and lose of human force and time. Making Guix Home part of Guix was and still is a commitment, in particular the commitment that we=E2=80=99d all be working on one implementation, that there are no =E2=80=9Ccompetitive incompatible implementations=E2=80=9D. It=E2=80=99s a choice we made, not a phenomenon = we=E2=80=99re passively observing. [...] > The new text-config serialization implementation (after fee0bc commit) > doesn't support gexps and tries to insert the literal content of the > file in place where file-like object was used, which > > 1. Confuses the users. > People reporting that it's hard to implement something like > > source \ > /gnu/store/00fl96dj2aak4i1vqvdqzlhbmmskc7fx-blabla.sh > > with the new approach (using file-like objects), and they switch to the > original implementation of home services for shells (the ones currently > living in rde repo), which allows to use gexps. Are there Guix Home issues reporting this? > 2. Looks strange implementation-wise. > > If we want to insert the file path to file-like object for new-style > text-config internally we do something like > > (mixed-text-file ... > "source \" "\n" > #~(read-everything-from-file > #$(computed-file "unecessary-file-name" > #~#$(local-file "blabla.sh")))) When would one write such a thing? A couple of examples from Guix System: has an =E2=80=98include=E2=80=99 field take accepts file-like objects, has a =E2=80=98config-file=E2=80=99 field. Guix System users probably never have to use complicated constructs like the one above. Why would it be different for Home services? Are there any new arguments since the already lengthy discussions that led to fee0bced7fec2f9950957976a28f033edd4f877c? Is it really what=E2=80= =99s leading to Guix Home being stale, or is there something else? Thanks, Ludo=E2=80=99.