From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.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 iFmHLSEg22GY1wAAgWs5BA (envelope-from ) for ; Sun, 09 Jan 2022 18:49:21 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id WBQsJiEg22EzfgEAG6o9tA (envelope-from ) for ; Sun, 09 Jan 2022 18:49:21 +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 6311F2C725 for ; Sun, 9 Jan 2022 18:49:20 +0100 (CET) Received: from localhost ([::1]:54812 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n6cJj-0000N2-Du for larch@yhetil.org; Sun, 09 Jan 2022 12:49:19 -0500 Received: from eggs.gnu.org ([209.51.188.92]:40648) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n6cJX-0000L1-7A for guix-devel@gnu.org; Sun, 09 Jan 2022 12:49:07 -0500 Received: from [2a00:1450:4864:20::131] (port=37542 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 1n6cJT-00035z-Np for guix-devel@gnu.org; Sun, 09 Jan 2022 12:49:06 -0500 Received: by mail-lf1-x131.google.com with SMTP id m1so3132268lfq.4 for ; Sun, 09 Jan 2022 09:49:03 -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=XitxMav7hW9HZ00TN3cGnOD/ctswNhqDM3C/+N/ZYBY=; b=reDF2Rk+y/pw/kdF1wyboARRxhSBKg9S7+SKf1HbXXP3SRINc7ecinRd8KGJz8FYTd bO9fQMMML5unlTSrgBcLESdTyk1Gw23NYHylQEpM0CbSOrNpmjjd17yJ545Rm+nw8hYm Thi7ET0RxfZN05sMN5NqmdOPM5rA9lLJHyiTbFD20yB6KWtuLEmfaBPs1T88BXMjMyz5 YG9uMqBFCr87C4Vy+hcQibAM/BVIldnHYZoaiYON2Y7EzDXEx7L+V8aAKLOWJO/a72ZB htvkRVrP58pU/WtcxjRtXioS4I8kYzUrObAn0i2iDH5/jbgtqK5LNJAJutcvNPhAlysP z9Vg== 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=XitxMav7hW9HZ00TN3cGnOD/ctswNhqDM3C/+N/ZYBY=; b=gqMCMmRv7nrnRLO/IdxysZho3B8af0DgTcpU1vhd0UWyB9BtoRAFpQtkApceFZmAC8 6iQOE3//pIr61TSOVzbI2nIW3+QNtbkcbO6oNKhfHJsSh8/WORwN2RMyecSjeTS5e58O R0W9jErzhsQ4gSWxxUvggrfta6EO1Mw78tJfZ2qEjEmdcf3DLsG049a/vLFnPQXwEHzq gm2n0+DCDHFgPbN3peZXsjmxlalKpzWAo+ktZTysbzlWQbUBqnUOJ5HsYOkSU+aIs/6c px81M9RENAgNAodT8zBtifcJzLanJc17M6hmPAL0K1lImdt6Nl4wBy/jHPPbAns/seN0 vq2A== X-Gm-Message-State: AOAM531fEbeB8auGA7svmN4ndAhhZMSfhR4TLUXmP8vsS9IAImsKRlxp 7m/qfi77yLEuH+N9/NajpMs8/A== X-Google-Smtp-Source: ABdhPJxO+Rt5AzzJNLavcNhwPjK3p7CohpkcPxzYDj0NZdi5i9NWAEFhqfbF+e/CRSkXixhkQXhrng== X-Received: by 2002:a05:6512:3c97:: with SMTP id h23mr64509171lfv.432.1641750541316; Sun, 09 Jan 2022 09:49:01 -0800 (PST) Received: from localhost (109-252-167-227.dynamic.spd-mgts.ru. [109.252.167.227]) by smtp.gmail.com with ESMTPSA id bt9sm706876lfb.206.2022.01.09.09.48.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 09 Jan 2022 09:49:00 -0800 (PST) From: Andrew Tropin To: Liliana Marie Prikler , guix-devel@gnu.org, Oleg Pykhalov , Ludovic =?utf-8?Q?Court=C3=A8s?= Subject: Re: Return back original implementation for text-config serialization In-Reply-To: References: <878rvp1deg.fsf@trop.in> Date: Sun, 09 Jan 2022 20:48:57 +0300 Message-ID: <871r1g4x6e.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, 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=1641750561; 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=XitxMav7hW9HZ00TN3cGnOD/ctswNhqDM3C/+N/ZYBY=; b=Fb1etHpLAFvjfxpn5F9OmDsuBnYzgR1Birdgjxq8JLunoi6tIo4R+lldgZULAaYaHq7/Am 0fjhgUHdFqZtHPOdqGDpG/kqLiwixRqIc/xuPM8tvKpq3xYRBVCgUL1uG3ZcvrHszbojbV vevQ4Hm0CYNZJMLa7SEADfp5zR789fzgtm//zM0iN8PF5oyrNgvbd8iy3uU0JbhOUzcjyW p649RiYMBjtoXI8+I8/xDU0cNCpGPfOdb+wr4ojQAON+su+lKtx84ymICnEwZYgkMHxZZq YypO+1ahWrvu9KH8ALKaMN3sGxvw6DAqqtQjTCFFgsi6cvQJTqeaLdluPMzmvA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1641750561; a=rsa-sha256; cv=none; b=LGVhdDj4OvKZBrOn8Yf8j74/GudPmFCTjTUQktucK+OLqQ46L28GzHOuOJ6pBjupKHYOuy 5RePj4OJjjyGLPrAUiaTlvrNasD6zk8b9Q5vCgyYkzCEWTgnzZuFAIKF31GInhGnOtec/3 u4Sa1xVtDITFvo+Oa8raCM+yaMzheRlGRGZdp5Uy/tPpWH2rhhMq2FdToCmuClJr+ZQxZH CFo0o/0JGv9uL3jB5PtGonn/Q6HvLmnvZenvrnESoTIUMeg7g1B6b0A6sakPALITXl1VXd R2RmlgH8Z+jnuiJLTkfC2Wp0MNF3E+2Fgl9GY6NH2J4HcjkyIqeeKJvQa3CUoA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=trop-in.20210112.gappssmtp.com header.s=20210112 header.b=reDF2Rk+; 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: -9.91 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=trop-in.20210112.gappssmtp.com header.s=20210112 header.b=reDF2Rk+; 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: 6311F2C725 X-Spam-Score: -9.91 X-Migadu-Scanner: scn0.migadu.com X-TUID: yaDi9qX42Ah6 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2022-01-09 12:19, Liliana Marie Prikler wrote: > Hi Andrew, > > Am Sonntag, dem 09.01.2022 um 12:12 +0300 schrieb Andrew Tropin: >> Before fee0bc serialization for text-config worked this way: >> --8<---------------cut here---------------start------------->8--- >> `("string here" >> =C2=A0 ,#~"string valued gexp" >> =C2=A0 "source \" >> =C2=A0 ,(local-file "blabla.sh")) >> --8<---------------cut here---------------end--------------->8--- >>=20 >> would yield something like: >>=20 >> --8<---------------cut here---------------start------------->8--- >> string here >> string valued gexp >> source \ >> /gnu/store/00fl96dj2aak4i1vqvdqzlhbmmskc7fx-blabla.sh >> --8<---------------cut here---------------end--------------->8--- >>=20 >> [...] >>=20 >> 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[.] > I agree that the old one looks nicer in this context, but wasn't the > new one introduced to solve the issue of (slurp-file-gexp) in the > importer? Meaning whichever way we go, we need something that allows > us to insert literal file contents of another file at more or less G- > exp compile time. > From=20my experience the usage of slurp-file-gexp is somewhat really rare, so I didn't upstream it originally, keeping in mind that it is possible to use the gexp mentioned below directly and that later we can add slurp-file-gexp or alternative if necessary. Just missed that importer already uses it. We could just do something like that instead of slurp-file-gexp: =2D-8<---------------cut here---------------start------------->8--- #~(call-with-input-file #$(local-file "./files/bashrc") (@ (ice-9 textual-ports) get-string-all)) =2D-8<---------------cut here---------------end--------------->8--- Or just take the implementation https://git.sr.ht/~abcdw/rde/tree/47f6c65c82a4f6761fa1ff5b9405b363cfda6482/= gnu/home-services-utils.scm#L90 and rename it to read-file-content-gexp or somewhat more apropriate and use it. >=20 > Perhaps that issue could be solved, if instead the importer just reads > the file contents and declares it as a variable as in (define %bashrc > " ;; Original contents of bashrc ") (define bashrc (plain-file > %bashrc)). > > WDYT? > Another possible solution, but I would prefer to stick with the direct usage of gexp with the code for reading a file, because importer is intended for creation of an example configuration and user will need to continue the work on it and copying the content of bashrc and other configs to scheme files, escaping string can be a little tedious. >> If we want to insert the file path to file-like object for new-style >> text-config internally we do something like >>=20 >> (mixed-text-file ... >> =C2=A0"source \" "\n" >> =C2=A0#~(read-everything-from-file >> =C2=A0=C2=A0=C2=A0 #$(computed-file "unecessary-file-name" >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 #~#$(local-file "blabla.sh")))) >>=20 >> when originally it was >> (mixed-text-file >> =C2=A0"source \" "\n" >> =C2=A0(local-file "blabla.sh")) > Is unnecessary-file-name ever created in this instance? I think we > have something similar in other locations as well, where G-expressions > are merged -- public keys for substitutes spring to mind. Perhaps all > it'd need to make use of new-style text configs is a better way of > quoting such things, e.g. a procedure which takes a file-like object > and produces a plain file with its name. > > For the record, the use of (read-everything-from-file) in your example > -- a procedure which I'm unable to find in my local Guix checkout -- > makes it somewhat difficult to come up with concrete solutions here, so > pardon me for being abstract. read-everything-from-file is just a shorthand for =2D-8<---------------cut here---------------start------------->8--- #~(begin (use-modules (ice-9 rdelim)) (with-fluids ((%default-port-encoding "UTF-8")) (with-input-from-file #$COMPUTED_FILE_CALL_HERE read-string))) =2D-8<---------------cut here---------------end--------------->8--- a gexp used in https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services/configuration.= scm?h=3D2c451db39aabc69bdbf186f412ee6e0b4e180ccb#n386 The example was already verbose, so I decided to simplify it a little bit. Actually, it's very similar to what slurp-file-gexp does, but it's moved inside serializer and hidden from user. Why not to give it to the user and eleminate two more layers of wrapping in gexps and file-likes. To demonstrate the idea of those additional layers, I'll "rephrase" the previous example in slightly different form. Originally it was: =2D-8<---------------cut here---------------start------------->8--- (mixed-text-file ... ;; evaluated to path to the store file-like ;; evaluated to the string value ; 1 gexp ; can be the result of slurp-file-gexp function if we ; need the file content ;; evaluated to itself "string") =2D-8<---------------cut here---------------end--------------->8--- It became: =2D-8<---------------cut here---------------start------------->8--- (mixed-text-file ... ;; evaluated to path to the store ; 2 (read-everything-from-file (mixed-text-file "intermediate-name" file-like)) ;; evaluated to the string value ; 3 (read-everything-from-file (computed-file "intermediate-name" gexp)) ;; evaluated to itself "string") =2D-8<---------------cut here---------------end--------------->8--- New style is not that bad, especially having some helper functions (get-file-path file-like) and (get-value-of-gexp gexp) for 2 and 3, but why? Especially, if we can have only one slurp-file-gexp like helper for 1, which is rarely used and maybe not even really needed. =2D-=20 Best regards, Andrew Tropin --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJDBAEBCgAtFiEEKEGaxlA4dEDH6S/6IgjSCVjB3rAFAmHbIAkPHGFuZHJld0B0 cm9wLmluAAoJECII0glYwd6wBBwP/3z+73jZpYL+dmuPK31YEWjUpf/PFYPB80SC 5MGZhVS9/Wk1MEIWjCyzuKbh5VtnW2pmZjq0QXess45jHA1a0e6iNnLey3cDk7zc jQJyj6b/1WVNwLlrGYlCfFC3WJ3QZOymqXcwJSucTYtvMIpzAiuDCgVOkTYSsEfV Uysmrt7i+SXPCK1YhaToXYir29xMWQOIWWMRjTZSDeL6S99NHXA8zy80oj0zQeTD jPV+g0QVVlO7e0MXa2PUPGtPPFBZZXKdzXRVGmdyaQPjkkbC5ACN9KPCVmm8rMas HRNDMUIHxi/9K5ZiZbXKj8AcdpnnLCS6LsWfRDBeXZzqN/t2P8t3Cmy4nXntasls z0+B42djnovCRtYwXQrOvYxS89Kefjm+UUhS5ZFchlGJQPWiHnrY8qIwzRiItgot 8nQn7rotQaazRo90dQUB4veOcYHpdoW/TBOGwEZxVEPbE0fSX+onFyfvVTHciFOq Qrf1TYRh16qLHYtZtf6j/i8Qa1AB5e6t5Jwx6zUpiA4v1U05yR94fWFY3F7QqpB1 vcRYoDceDjhSSNoS2jmQ2wbF9Q8V85eQpmdJWyD4mzALaY3nqGDZipCmYRHcya49 3W8Vc4K+DraebziNfpuwqoBOiX292r/5HhNAIWTbOWt5BJzxH47fLLNg2HIiURMT sqcWvb+y =12hv -----END PGP SIGNATURE----- --=-=-=--