From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id cGNuMRGn2mF0WgEAgWs5BA (envelope-from ) for ; Sun, 09 Jan 2022 10:12:49 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id 6ATLLhGn2mEEwAAA9RJhRA (envelope-from ) for ; Sun, 09 Jan 2022 10:12:49 +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 4688C29177 for ; Sun, 9 Jan 2022 10:12:49 +0100 (CET) Received: from localhost ([::1]:40296 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n6UFs-0002gs-Eh for larch@yhetil.org; Sun, 09 Jan 2022 04:12:48 -0500 Received: from eggs.gnu.org ([209.51.188.92]:52728) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n6UFP-0002gk-A2 for guix-devel@gnu.org; Sun, 09 Jan 2022 04:12:19 -0500 Received: from [2a00:1450:4864:20::134] (port=37401 helo=mail-lf1-x134.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n6UFK-0004gT-K3 for guix-devel@gnu.org; Sun, 09 Jan 2022 04:12:19 -0500 Received: by mail-lf1-x134.google.com with SMTP id m1so123858lfq.4 for ; Sun, 09 Jan 2022 01:12:13 -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:date:message-id:mime-version; bh=vmW49ZZuKajMCS2S0DQ1qWTq+SRwmsjo2rh7wPE/jr8=; b=XoA2wN6n1GdZeQ4+zXYVZCuFIAFwlYEAgigUlD/0Jf8w5kRdbZfRMrUNb9pdLCHSKF NpY+5ruUOVLB0r0laMHygfRoOhIHaKxou4UxxRoctThd1WmKoT3LAZg9JPD0LnOpAHuO sQhongXFjeeJ+QmjesNr8OoPVvPfUAETDSxcBu3J5DbpaifbuzZb1qAYGEr9N5hPYeUQ teHoyxBO/hJ8gx2RbrjPaxggDx/B2nBqB+zt9CiHZMfV2/QAj5nVSPXVmRC8RWT0m4xC +tv+bGodcWCe07Bjd2oEcGoSWYcnH3R4orFiASMdfTCYvW1pyl6TqkJ7/j3umMUuc0VI W1/w== 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:date:message-id:mime-version; bh=vmW49ZZuKajMCS2S0DQ1qWTq+SRwmsjo2rh7wPE/jr8=; b=XRSM4grZGojPuTUGYl9tnBb2UHPeBrD0tOtXr79+i7wtuHhYPs5FOkcXI3PX83U1De WW+ziWAPhYrMOliZEs0it6/n27FWjLNIs9TM5t6nMbOkyxELXRx7Qk/WklieNWOIiNyo wpYH05e/ESa4IgDfFn3Ghk5UFfCP/U6SZq8WTv9iId5hmNdZweh+qiNudr/eN+suWjAI 158y5YPOvsMdOE+RTF8Kg0a+E5cXaThwpurwv6GvOJQ/dDlLdLRo5rhq8qDTdF7LNvX9 e+z857cXXb99sLpbOSrKVTm4Q8fGr4lRVplBArDeAYZaybsDT/uBB/IMCagyi8zykBLr 5iMw== X-Gm-Message-State: AOAM531RaXBsvWJXP1hPTroiHJrPiHAwc/EDN9JLgkpp+9mCk1bbCO5g oBApsFDOrQgOU3ZIgr7Q93Hf+HBQySC/jOh2 X-Google-Smtp-Source: ABdhPJzWaZifKjdSN5yPEol9rdwR4JbA9IH06AqHhFpKkXWjw92SGphJbiunXNFGemMJPd2pYFLZzw== X-Received: by 2002:ac2:58cc:: with SMTP id u12mr2098410lfo.263.1641719532142; Sun, 09 Jan 2022 01:12:12 -0800 (PST) Received: from localhost (109-252-167-227.dynamic.spd-mgts.ru. [109.252.167.227]) by smtp.gmail.com with ESMTPSA id w25sm552782lfl.155.2022.01.09.01.12.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 09 Jan 2022 01:12:11 -0800 (PST) From: Andrew Tropin To: guix-devel@gnu.org, Oleg Pykhalov , Ludovic =?utf-8?Q?Court=C3=A8s?= Subject: Return back original implementation for text-config serialization Date: Sun, 09 Jan 2022 12:12:07 +0300 Message-ID: <878rvp1deg.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::134 (failed) Received-SPF: none client-ip=2a00:1450:4864:20::134; envelope-from=andrew@trop.in; helo=mail-lf1-x134.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, 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: 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=1641719569; 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:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=vmW49ZZuKajMCS2S0DQ1qWTq+SRwmsjo2rh7wPE/jr8=; b=PFk6R9pvNqHhQy8JBcGEZVjb/RWmu5QCyac/Hnt3CmyyT3J1Iyue6W3JArUfkkTGbqHx2q SQdxNTIGko7KLQyYbBX/PGe4yMYZrZ/6WLikeG2M5FMUVDnDPUFiUZZhzF+/CIQxa102es XUy3D1mVOJSSE45KTtcDNUwpe9EHswXJsJ50lFdKL0nL1PcaK2gzzGpwdIiXEQ89XLLa0+ D6QxUc+hdhnmgLd3MLD3jCT5MYWeO9eAqYys8IHWzc0rHcTR3woXvUgy5YBpDR+wP8rkEy vLzY/HqbG2GBiNsABDGU1+UsNYHNwTxontaiFrNoF5gHlv645B3MVgZy1xuypA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1641719569; a=rsa-sha256; cv=none; b=Fb3Cr0/ScGDztw8iYDtvQIpEBBp7gOsx+0uImQVA4k6VzgXhVd1w2yMyI98yHVHRgOVLqn eP2Abot4NWYMAeFwnzFdqPFQnRQDoBc9HyXgAPEMBAzeuW/PXlRLVDSXFzq/JL0AApLgy3 209s1ucyAaCWfKaJ0UiHxQtmJvpygZGMXOU+xeELVXOng9oNXVE5FvQuA+a5AyH788U08O FNdugp1oaexSJbJMv4586VnyOe40himm+ObUQ2yEraPQ2FcQED4T6o43zYGJ7Fgqjq/579 yI/47oal1/7KjO9Lg0E7R2u/MjT/Y1TcPxfH65MSHHMBGjT3K4M+1MrdGzsEug== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=trop-in.20210112.gappssmtp.com header.s=20210112 header.b=XoA2wN6n; 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.71 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=trop-in.20210112.gappssmtp.com header.s=20210112 header.b=XoA2wN6n; 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: 4688C29177 X-Spam-Score: -5.71 X-Migadu-Scanner: scn0.migadu.com X-TUID: fKKQy9J44S2w --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable 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/configuration.= 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/47f6c65c82a4f6761fa1ff5b9405b363cfda6482/= 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/47f6c65c82a4f6761fa1ff5b9405b363cfda6482/= 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. 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. I wanted to solve this question as a part of https://issues.guix.gnu.org/52698, but seems it doesn't get enough attention (probably cause of the volume of information in the patch). I'll provide a few technical details, which supports the original appoarch. Before fee0bc serialization for text-config worked this way: =2D-8<---------------cut here---------------start------------->8--- `("string here" ,#~"string valued gexp" "source \" ,(local-file "blabla.sh")) =2D-8<---------------cut here---------------end--------------->8--- would yeld something like: =2D-8<---------------cut here---------------start------------->8--- string here string valued gexp source \ /gnu/store/00fl96dj2aak4i1vqvdqzlhbmmskc7fx-blabla.sh =2D-8<---------------cut here---------------end--------------->8--- There is another less generalized example, which demonstrates how serialization of sway configuration works right now. =2D-8<---------------cut here---------------start------------->8--- `((include ,(local-file "./sway/config")) (bindsym $mod+Ctrl+Shift+a exec ,(file-append emacs "/bin/emacsclient") -c --eval "'(eshell)'") (bindsym $mod+Ctrl+Shift+o "[class=3D\"IceCat\"]" kill) (input * ((xkb_layout us,ru) (xkb_variant dvorak,)))) =2D-8<---------------cut here---------------end--------------->8--- would yield something like: =2D-8<---------------cut here---------------start------------->8--- include /gnu/store/408jwvh6wxxn1j85lj95fniih05gx5xj-config bindsym $mod+Ctrl+Shift+a exec /gnu/store/...-emacsclient -c --eval '(eshel= l)' bindsym $mod+Ctrl+Shift+o [class=3D"IceCat"] kill input * { xkb_layout us,ru xkb_variant dvorak, } =2D-8<---------------cut here---------------end--------------->8--- 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. 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 originally it was (mixed-text-file "source \" "\n" (local-file "blabla.sh")) 3. Inconsistent with other home services. I do not insist that one approach is superior to the other and there are of course some pros and cons for both of them, but personally I find the old one to be more user-friendly, simpler and cleaner. Also, having the new implementation stops me from upstreaming all other home services, because almost all of them allows to use gexps inside configuration field and resolves file-like object to the path in the store instead of literal content. Please, express arguments, opinions and rationales and let's decide: Keep the new approach or return back to the original one. =2D-=20 Best regards, Andrew Tropin --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJDBAEBCgAtFiEEKEGaxlA4dEDH6S/6IgjSCVjB3rAFAmHapugPHGFuZHJld0B0 cm9wLmluAAoJECII0glYwd6wtdcP/jomMVUwBKHVFpLSA1o0lZ15RDYGWpRBjApn LUepawk00TUepgzFaNJrVvGDQfGcHjcltwZ4tfmsyQMhs5rJ3ZMklGO89j1elvdg 0tZyIHAxZMbv6KvcthoRXCk3CFubEX6tIyL3N4V6glEG0z9ZYq3z+DX7Dh9iFiEJ jyoghoz9GzgARxBaxQ4tCD+SK1kXHQP66+KbqyAlwDtPXu8g+409orzyg/v88coT 62Pux19U+3sJnW41UAzP4SBnZU6vy8bb9XOROqFLSwWkH96j8PkXQQFJr6Wns0pL XZ+hbt3TbJvXsv8wfWFPRJ+i6pttL+gl4pb+uYEKFiFLY9I/H3z9Qqy4RuNosuRz I8SIeV4ER8LW8M5a6nyGKG9+FRvE8qcv1bsvIRm5+aRkBTp9Hiz0D0YOakkWzo82 l0a6pJbFv+iutn0oQ37fXTpubZS1T1qXX+LWfarEZiB2C/psiq8KQM18Dg2s1dmh EohBD97i8LY/T2fj731TzZzmxpKg9kl/5WQe8Z6RatsYgMKql4EbpAHyb6S+On90 XTxIVjzXfwok1iEkKGAqOea/6uuztxdqz9vcbf6654FZ4MJQg7YuqQk4J49yw9wf qoYEfXr4+hIKNdtdaYuJF51W4Jv9dJGPtuUUvbGJtvJ2NpRIGB6QbZUP4s37pRt8 pI71hNZM =+i2S -----END PGP SIGNATURE----- --=-=-=--