From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id YJDTCd+p6WEvRwEAgWs5BA (envelope-from ) for ; Thu, 20 Jan 2022 19:28:47 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id qDWEB9+p6WGeXwAA9RJhRA (envelope-from ) for ; Thu, 20 Jan 2022 19:28:47 +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 9006544844 for ; Thu, 20 Jan 2022 19:28:46 +0100 (CET) Received: from localhost ([::1]:50408 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nAcAv-000782-Mt for larch@yhetil.org; Thu, 20 Jan 2022 13:28:45 -0500 Received: from eggs.gnu.org ([209.51.188.92]:53134) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nAXN3-0002NF-I8 for guix-devel@gnu.org; Thu, 20 Jan 2022 08:20:59 -0500 Received: from [2a00:1450:4864:20::131] (port=35491 helo=mail-lf1-x131.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nAXN0-0001A2-EG for guix-devel@gnu.org; Thu, 20 Jan 2022 08:20:57 -0500 Received: by mail-lf1-x131.google.com with SMTP id x11so21591362lfa.2 for ; Thu, 20 Jan 2022 05:20:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=trop-in.20210112.gappssmtp.com; s=20210112; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=vJbXtvuQs6NGajnDt2X2VIM5EFd1jOenzdt4kPRcqEY=; b=apthgYhID2Zz65i7YjWGu8qDhb2Wb7wuAh53BjJmQn6ojAhJ4enK3onsLCyXTpPfG0 AHQM8dpmcI65V+6km4Wr26/inJimvBiuAiVLGxFkws/xi5xEF4tZ78imcDQ+0bmmjBZL rzpQwds0gqJ3xhk2twJ7TH14KuH1ot+ggOAdpcfJKoJFFEoGqXv/cdpghXw3IrSePfL+ IDP2R5fnt8nyLnoF7BrS+/UsaYFcCJaXMCwe6uTrnUKih3DzxfEEM+1OOqG0gSqha9z2 KplRUPi4EKSZN3xWLbJ3xqUmElcTRjflrMTQUmaOmaFaNRNn6x5TEvV36GOFLLYd0tos 6GEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=vJbXtvuQs6NGajnDt2X2VIM5EFd1jOenzdt4kPRcqEY=; b=sikO8vSko+Bs4nAglYlFiQcCPdW6DfEi89iVYDnX2HKaLQCDWKzD+oWc8t9Cv00qef 5pZnrfPhE6dCNsjwlzYjho37w7mf2OHEiUG1VC6pgpnBZd7OX6Yes5WDiUGWrYiCj6Os L5xBK00jcM5FwgOuT6gKToH7NDDabvkBUZWGNGOyc7RP3Kl3ONhUoSSEIDux3exSXbOk bvoNWeHlQDZ3sHan0hJZlKj8WRXMsYxEIhHIkCl0DVJPxR7rWtqcwVaSLbTIGqnp0W0Z co/Ygk4rY71Gl4rNfSh4RT/dB4a2dSlux+tYd78F+92sUVTdS34UXmxLmamYiDoGE/2T 9rNg== X-Gm-Message-State: AOAM53224vW0BCUDvzTCvgAtZHDldtTypgFYqONHXZwuyxQ1rjTD72uk INd1VM3Jt7E4V2qmerl1rTshCMqiZWCMNg== X-Google-Smtp-Source: ABdhPJzeW4xsZnm1mbQb4hcvqWwziJELYdRFfKXFNTx4r3z4QlFux4s60bK3ieSUnyDsLsLvTw78jQ== X-Received: by 2002:a05:6512:1395:: with SMTP id p21mr8242854lfa.25.1642684852688; Thu, 20 Jan 2022 05:20:52 -0800 (PST) Received: from localhost (109-252-135-33.dynamic.spd-mgts.ru. [109.252.135.33]) by smtp.gmail.com with ESMTPSA id w18sm277600ljh.119.2022.01.20.05.20.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 Jan 2022 05:20:51 -0800 (PST) From: Andrew Tropin To: Ludovic =?utf-8?Q?Court=C3=A8s?= Subject: Re: Return back original implementation for text-config serialization In-Reply-To: <87mtjtglxd.fsf@gnu.org> References: <878rvp1deg.fsf@trop.in> <87mtjtglxd.fsf@gnu.org> Date: Thu, 20 Jan 2022 16:20:48 +0300 Message-ID: <87o846y24v.fsf@trop.in> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Host-Lookup-Failed: Reverse DNS lookup failed for 2a00:1450:4864:20::131 (failed) Received-SPF: none client-ip=2a00:1450:4864:20::131; envelope-from=andrew@trop.in; helo=mail-lf1-x131.google.com X-Spam_score_int: -5 X-Spam_score: -0.6 X-Spam_bar: / X-Spam_report: (-0.6 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, PDS_HP_HELO_NORDNS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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=1642703326; 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:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=vJbXtvuQs6NGajnDt2X2VIM5EFd1jOenzdt4kPRcqEY=; b=KDpWaQD64CEWbzWssoMO2ps3OCQUApaLsdwK2NhzHtPDdgi3M7duyC7typl2f7giu9vEMc pp2FvCDCvSb4xPVj4M4KHdkl3tFAryVAY24cRwfNTE/ZeFahYM+PXQQIUVNu5IAWlTyNan oLLWdWiLaxON/ubER7Pj0+toho7RITy7mnIXDp15GiYVOy9Ji31MjLH2LmC/RMbabCA+HA etTUQsDKmxWcKnZ2eEfADYSjDnYc7h4DdpS8SDql4Zu4GDwPV7iHgChA3jhiPKSO1Ssjk7 r5LYyh2es6z/kNaHVaW4LsnSscvlofy2ZBRiu9iSm6pzsr2uvIK6uKsFoSSkLg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1642703326; a=rsa-sha256; cv=none; b=VnvmNj+iMZnoCcgaY7UJOGxDU0YTuUCnIg/LyaGOyGRi9AXWzMpPLLcxeu5h8XYkOmnVP0 79PYGun0VM019W0jQhWoMquBQLMM3V6nsvg7cYqLnCcYAKE1F41yF6INL2b5S4tbYMx8g0 UZaNo0m7dB8mTCraxrSCij1pMTZ/S4L/MuK9kxgOZOX5wzg0umHo9B2nVhJiLBbK5DcZEn aGZmry3N76OtWttHYm2jGdC5t7YCtTaiSMF7NRqJj3VtnOABSnTEXoI+eUsTMRy7zlV9qn lMHh3RUSa2jgY7DUwzfMuHEaI6NFouA78zE0OVYSUWDcH309BHw2E3VPhXVcmQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=trop-in.20210112.gappssmtp.com header.s=20210112 header.b=apthgYhI; dmarc=none; 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: -5.02 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=trop-in.20210112.gappssmtp.com header.s=20210112 header.b=apthgYhI; dmarc=none; 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: 9006544844 X-Spam-Score: -5.02 X-Migadu-Scanner: scn0.migadu.com X-TUID: IUAqMHuYEMJs --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2022-01-18 15:26, Ludovic Court=C3=A8s wrote: > 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/configurati= on.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/47f6c65c82a4f6761fa1ff5b9405b363cfda64= 82/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/47f6c65c82a4f6761fa1ff5b9405b363cfda64= 82/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 = Home 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. > Hi Ludovic, It's not a justification for the changes it's a recap of the past events to provide the context. We were working on moving Guix Home and home services from rde to guix, but in the middle of this process the change to text-config type happend and now it's not possible to continue upstreaming without rewriting the rest of home services in rde repo or reverting back this change. > >> 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 phenomeno= n we=E2=80=99re > passively observing. This is exactly what I want to achieve: To be able to collectively work on one consistent implementation, but fee0bc, which slipped to the master unreviewed, splitted home service configuration approach into two competitive implementations, a few essential home services in guix repo and bigger rest of non-essential stuck in rde. I already mentioned at least two possible ways to handle this situtation: 1. Rewrite the rest of rde home services. 2. Rollback this change. I'm ok with both options, but #1 requires much more human hours to complete and I still not sure if fee0bc was introduced for strong reasons or was added almost accidentially. So I try to find a justification for this change. From=20what I understood from Liliana's and Maxime's replies: I'm not the only one finding the original implementation to be more intuitive and consistent with the rest of Guix API. Please, correct me if I'm wrong. >> 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? > Just a 3 cases I observed in Guix Russia telegram chat. >> 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? I have very same question :) It's what happens internally in current implementation, something like that goes to home-files-service-type. > > 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. During the course of this year learned a lot of different service configurations and approaches used in them and aware of this too. We can also mention some services, which has a special field, which accepts a list of strings or string-valued G-exps, which will be added to the end of the file like xorg-configuration or httpd-config-file. Those approaches have their own pros and cons and I already shared some thoughts on this topic: https://issues.guix.gnu.org/50967#65 Also, I already started work on 'Writing Service Configuration' section in the manual, which is good platform for discussion and should help to align our visions about service configurations and prevent some unecessary discussion in the future: https://issues.guix.gnu.org/52698 > > Guix System users probably never have to use complicated constructs like > the one above. Why would it be different for Home services? Users won't use this construction directly, it is just what hapenning under the hood and looks a little too much excessive. > 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? IMO, changes to text-config in fee0bc really makes it harder to continue the work on many Guix Home related tasks. =2D-=20 Best regards, Andrew Tropin --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJDBAEBCgAtFiEEKEGaxlA4dEDH6S/6IgjSCVjB3rAFAmHpYbAPHGFuZHJld0B0 cm9wLmluAAoJECII0glYwd6wIrIP/RTJlW1rIAND1e+CN8kCGWSB3fkgaWEz+NyZ 3vnsAbzCncKbNmCIWwl2NR0R9ZafGSn+h7svGbhJuijixj0tUIa7TZY/v+EFbA4G SfPaGE/xq/Xf3nkD/jeiJjetCFyAsCOkoxMuD94kzuK4yRKWeBRlsJ8clfUXV6jz eb0qvAi4mKBP8QQyusYvl40XggTY15YNdAQ4Ve8WKffGLa6gx8iI9xsbKTBNKnwC KP/gGHtMRcs5YxZH71cDSLP2nGBNSbqZl1YkFbRYYBsm5k76ayOsPd4qB4QZge6W /DeO7HMWnRQZmWQ+fMZRIQUb/NXajAL8kYbWH5C5VRNkBk9ThFX6qcC20DnfYtEa alToBiycjaDQjf5uwb4nyCeGp6FYYDVJyE8GRkYL5XQAOeDp+MXyJz/s7E2v7Yvr rTZcw5RnnPBWADMaVqkQvjivT/rnryz843K5jk+3GUkRzVOr/ZR6ypzujQH4KV+M WUo7XABkfZyhWRrZBcPjX5s2WoA40fMQjkDgfvuoLS3T01vvOH8MKRFi/tTm3GQ5 77hcMnrV2Aquw0QNElOeB5hEblq7faqNt0GcjYoq6DZaE4bPDxuE5WAda3VSRc3J 9+s9S87zWq8GFwLtX/ZYp8yt/2KHsJzqeZG8vBIs63VHRCQrmr3v/Z+/kU7o+5NP ki18MT6n =0cOb -----END PGP SIGNATURE----- --=-=-=--