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 GDkJI2gB3GExCAEAgWs5BA (envelope-from ) for ; Mon, 10 Jan 2022 10:50:32 +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 NmhrIGgB3GE+0wAA9RJhRA (envelope-from ) for ; Mon, 10 Jan 2022 10:50:32 +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 E09D413E50 for ; Mon, 10 Jan 2022 10:50:31 +0100 (CET) Received: from localhost ([::1]:55450 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n6rJu-0000oG-MJ for larch@yhetil.org; Mon, 10 Jan 2022 04:50:30 -0500 Received: from eggs.gnu.org ([209.51.188.92]:33490) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n6rJX-0000o8-6h for guix-devel@gnu.org; Mon, 10 Jan 2022 04:50:07 -0500 Received: from [2a00:1450:4864:20::12b] (port=44826 helo=mail-lf1-x12b.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n6rJP-0007qN-IL for guix-devel@gnu.org; Mon, 10 Jan 2022 04:50:06 -0500 Received: by mail-lf1-x12b.google.com with SMTP id g26so42217604lfv.11 for ; Mon, 10 Jan 2022 01:49:58 -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=fOLbt8v/EY2d1MHV1nesHVRLy3rqKFWbjvj4F7vA8s4=; b=mp41i6W+P06ija0wH6KPNGxmBuQJT6dbcmoU5+ZbLEVZSsmFrFfO6Wl1T0ulGd/GYV rU0xrWLKv5Dzg0BIbs1k43/cbC7DuJxgVRaAWDLNEYndT5gJpO4pJEBNti2eZzQE59H3 s/XLrI1ME5DmXGAkHMsoW/x6LzfaeNMmFRs4E6xZK7LlMdXQEgi5RKx7e++LQdc0fDZm ofYOfAgV7frWIK+5O3pHoIFlqU3s2AmT7FFPIJg5fAJgbtFapBy4nxw9zLKARJhj5gl8 po2qpLUgHOvEcAkMW2LPit72D3IAqNAYbtcp/xC7wa4x/6KZmlE8zqJVC+njieHF/aNN yfAg== 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=fOLbt8v/EY2d1MHV1nesHVRLy3rqKFWbjvj4F7vA8s4=; b=oeqs5utIThLTQzk4y/PGFAlIA6U88plSkoXQU49x3gMdFZcx7bhfZ17whaqSn1VZek AaGxbVB+sqQEfLB3XuR/q10f64zl7EElB/dV8eMtLPx5TnMoyH1w7TWtHGkArMv58pJB z2+nlq8hpfuj5FtVqp/Am5XI5a9caUt/anTcG2lfZRLlx9hJ+ZfsJFQ8dNMv3Of7YpDK 5ELws2a/v5gbHeF88LG8QGgbpqd15VhU9eRam9MzUlKb5FOjT69MZQyOuRb7YJ1s9TVw UO0aIGB+DLZAg4x9rS881WTN563GzoDADDK7g0evzHqNhfnacVaOj3v/gOld0nWIgn4N xU5g== X-Gm-Message-State: AOAM5308NHdXZoJQukwYh9dIMCsTui5tpr/v5IOh6F7hgnJN+fkxNs72 SJbzHeKL+l8a2RKqeXB/M3X7JQ== X-Google-Smtp-Source: ABdhPJw39km8htU5vAGONBFegZ1+sFyxHjPI8zWuGr++3YeoeYCJ0NhbTvOrti/+9+leWzuKgIXLQQ== X-Received: by 2002:a05:6512:2292:: with SMTP id f18mr61916175lfu.51.1641808197485; Mon, 10 Jan 2022 01:49:57 -0800 (PST) Received: from localhost (109-252-167-227.dynamic.spd-mgts.ru. [109.252.167.227]) by smtp.gmail.com with ESMTPSA id y34sm1018764lje.10.2022.01.10.01.49.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 10 Jan 2022 01:49:56 -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: <888e529cb04bb74bfd98f8e07db0c522efee9251.camel@gmail.com> References: <878rvp1deg.fsf@trop.in> <871r1g4x6e.fsf@trop.in> <888e529cb04bb74bfd98f8e07db0c522efee9251.camel@gmail.com> Date: Mon, 10 Jan 2022 12:49:53 +0300 Message-ID: <87mtk33oou.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::12b (failed) Received-SPF: none client-ip=2a00:1450:4864:20::12b; envelope-from=andrew@trop.in; helo=mail-lf1-x12b.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=1641808232; 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=fOLbt8v/EY2d1MHV1nesHVRLy3rqKFWbjvj4F7vA8s4=; b=tXKlE1rhQdJy4UZlg6r8UqtgMow9MYWCj7zXhC5YQQ6qEh9YKZhMOUrnzJquhXpUfJqMOW UpxX4cEspKIUWkFPI+JqfzvfAKNRlKzLtcwgC9MIzc+CTtk6KvgacBW2stABegyuHIjEhL I0/7iZwopluTF1y5ug4eipuG9FsFtja9EcPpGdfsPP3bcij3mlSmwNa0q9uTR+NSj7wJ82 AOEJsrTEGSEzuDqRXeTObY37Hdsst9Ko0ZF8eKqkPcWsomdKNtiDBwS3IG4pwVyUr4eeB2 BaE3uv1i4nyL4vKPZ6jAY84oS2YzFgSCGVD8trj1kR4kZOljTncRfjEbF1Kbqg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1641808232; a=rsa-sha256; cv=none; b=C31/omx1dPPpZrl+BzwAndWPEu3eDZT1hJDXfQA2xhz1lBspkmWGc9u4M8eA3U1J9PHX5z KnDczxIlmgRv5cG2UfuqOewLKjstv8QOyblarey11lEOg2zcZlC60z1lq+oAKnIHykj7K+ VJAb5Aaqf9PMkxD1TRAufwblVuoAWAgPHhdWkO8mV3x5700I2wN4yrj0F9waBvFy0XY1z/ YLAFWRdNNMYgYhefYlxdumiz8CgA7KL6dEPTMC72rJvV9LEoOk0TvRGnaelvqOt8vFm8Nh YMGOibssuhjECR+iRTkXW9FzHRBFLBTtx8UYtm0YNaoXH+evkBKRgUm6LBtjfg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=trop-in.20210112.gappssmtp.com header.s=20210112 header.b=mp41i6W+; 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=mp41i6W+; 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: E09D413E50 X-Spam-Score: -5.71 X-Migadu-Scanner: scn0.migadu.com X-TUID: 1pbuiMOsnlR/ --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2022-01-09 20:44, Liliana Marie Prikler wrote: > Hi, > > Am Sonntag, dem 09.01.2022 um 20:48 +0300 schrieb Andrew Tropin: >> On 2022-01-09 12:19, Liliana Marie Prikler wrote: >>=20 >> > Hi Andrew, >> >=20 >> > Am Sonntag, dem 09.01.2022 um 12:12 +0300 schrieb Andrew Tropin: >> >=20 >> > > 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?=C2=A0 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. >> >=20 >>=20 >> From my 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.=C2=A0 Just missed >> that importer already uses it. >>=20 >> We could just do something like that instead of slurp-file-gexp: >> --8<---------------cut here---------------start------------->8--- >> #~(call-with-input-file #$(local-file "./files/bashrc") >> =C2=A0=C2=A0=C2=A0 (@ (ice-9 textual-ports) get-string-all)) >> --8<---------------cut here---------------end--------------->8--- >>=20 >> Or just take the implementation >> https://git.sr.ht/~abcdw/rde/tree/47f6c65c82a4f6761fa1ff5b9405b363cfda64= 82/gnu/home-services-utils.scm#L90 >> and rename it to read-file-content-gexp or somewhat more apropriate >> and use it. > Using ill-defined slurp-patterns at all just adds ways of shooting > yourself in the foot. You're turning Guix into an ouroboros that reads > itself inside-out. Better restrict such patterns to where they cause > the least harm and make their effects very explicit. Not sure what you mean. >> > 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)). >> >=20 >> > WDYT? >>=20 >> 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. > There is certainly a tradeoff here, but I think explicitly showing > (plain-file CONTENT) is the right approach here. Users are going to > figure out mixed-text-file exists soon enough. As for proper string > escaping, that's not really an excuse imo -- pretty-print exists and > you can use it.=20 Yep, of course it possible, but I mean that the whole point of escape hatch is to make it possible to reuse existing files directly whithout any manipulation on them and importer should demonstrate how to do it. If importer internally do some manipulation (escaping) with the content of the file and places the result in the string in scheme file, user won't be able to replicate such process easily for other services, which not covered by the importer. If I understood correctly what you meant in the first message. >> read-everything-from-file is just a shorthand for >>=20 >> --8<---------------cut here---------------start------------->8--- >> #~(begin >> =C2=A0=C2=A0=C2=A0 (use-modules (ice-9 rdelim)) >> =C2=A0=C2=A0=C2=A0 (with-fluids ((%default-port-encoding "UTF-8")) >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (with-input-from-file #$COMPUTED_FILE_CAL= L_HERE read-string))) >> --8<---------------cut here---------------end--------------->8--- >>=20 >> a gexp used in >> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services/configurati= on.scm?h=3D2c451db39aabc69bdbf186f412ee6e0b4e180ccb#n386 >>=20 >> The example was already verbose, so I decided to simplify it a little >> bit. >>=20 >> Actually, it's very similar to what slurp-file-gexp does, but it's >> moved inside serializer and hidden from user.=C2=A0 Why not to give it to >> the user and eleminate two more layers of wrapping in gexps and file- >> likes. > That's like saying "memory management already exists, but it's hidden > from the user, why not let them play around with malloc?" In > programming languages that aren't C/C++, abstractions ought to make it > harder to shoot yourself in the foot. You (in my POV correctly) > pointed out that our current handling of text configs makes it very > easy to shoot yourself in the foot and is therefore badly abstracted. Mostly my point was that it's more intuitive to expect that file-like objects get serialized to the file path in the store and string-valued gexps to the strings (as they does when we use them in mixed-text-file for example), but new approach doesn't allow to use gexps directly and serializes file-likes to it's content and requires much more hassle. In both cases it's possible to use both gexps and file-likes, but in the second one we have a few more levels of nestiness of gexps inside file-likes inside gexps, which seems unecessary. > The point I'm making is that we shouldn't swap out one bad abstraction > for another, but pave the road towards good abstractions, e.g. G- > expressions in the way the rest of Guix typically uses them. Actually, for me, the original implementation looks consistent with how the rest of Guix treats G-expressions (uses already known abstraction) and only new one intoduces a new abstraction. We can treat slurp-file-gexp as an abstraction here, but actually 1. this is more a tiny helper function, than an abstraction. On 2022-01-09 20:00, Maxime Devos wrote: > That would avoid having to remember the (call-with-input-file ...) > trick. 2. this function is not really necessary. > > Now one thing I had not considered back in my previous mail was that we > want to be able to compose bashrc together from multiple sources, so > having the field be just one file-like object probably won't cut it.=20 > However, we can let it be a list of file like objects (with a field > sanitizer transparently turning a single file-like object into a list > either silently or loudly). And within those file-like objects, we can > use the usual semantics. I considered this option, but the problem is that we can't control the place where the content will be inserted. Let's assume it will go at the end of the bashrc (we can demonstrate the similar if it will be added to the beginning). (home-bash-configuration (bashrc (list "call_function_from_lib_A()")) (bashrc-content (list (local-file "lib_A.sh")))) which will make a call before lib_A loaded. Also, it's already possible to achieve the same with gexps/file-like in both new and old text-config implementations. In reality, it's rarely needed to insert the content directly, in most cases it better to source/include/whatever file from the store. With old implementation it will look like: (home-bash-configuration (bashrc (list "source \\" (local-file "lib_A.sh") ;; Or an alternative way to do the same with gexp ;; #~(format #f "source ~a" #$(local-file "lib_A.sh")) "call_function_from_lib_A()"))) With new implementation: (home-bash-configuration (bashrc (list "source \\" (mixed-text-file "unecessary-name" (local-file "lib_A.sh")) ;; Or an alternative way to do the same with gexp ;; (computed-file ;; "unecessary-name" ;; #~(format #f "source ~a" #$(local-file "lib_A.sh"))) "call_function_from_lib_A()"))) which not that bad, but still looks more verbose, less intuitive and consistent with the rest of the Guix (at least in my perception of it). * All the code examples are in a pseudocode and maybe don't work and used mostly to demonstarte the idea, provide a feeling of how final configurations look. > > I'm not sure how the current implementation of Guix Home handles > composition, but I believe the root of the issue probably stems from > there in some capacity. Might want to check what our requirements are. It's offtopic, but when you will have time please take a look at https://issues.guix.gnu.org/52388. =2D-=20 Best regards, Andrew Tropin --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJDBAEBCgAtFiEEKEGaxlA4dEDH6S/6IgjSCVjB3rAFAmHcAUEPHGFuZHJld0B0 cm9wLmluAAoJECII0glYwd6wJlEQAIhPxsMtQNbVkTQMXEVeXEM9ynnuDYv10XB8 eBONv61scgHmO/Z1lGPsoHUnZVZOZvRdTC7agaFIptJeUrn63ZIyYeSoyF74zVLX mqbg/rR2NZZrpZlS6xvZuWmR7yFtD/ueluFQWHpzMmygNHaEHKp6OmipchzawGbd h7IKv9GSVlLBRmKP+YzquM23P6FCMJauwbEfSACKB38uZebkN/FgDaSinw5Yw2qK pNLRi2n3eV5eBu6tbAg32yvoRlYHKBD0PDWPnbxQl2C2Y+XN5algGkJ109igDJDI Z0r8M4vpPzsSVBsMYwen+0IcR6aeo7DpBjY2BJMq9NHGLiPYaZ9r5ebCsqLaJwjG 5+IgZ5cxCQumtZP4PXaEmec3M9Zwvux1Bk4F1bUA85vfeq+y7JPazRJBiOjymgJI H1OBJnPNtb007dMelrqImZMPCseriT5eXcm5GjmGaAmBwgYPBnxffP5TJPqXml5A XBg1SKsnJRC6BLK3iMCvpH3vp8GW5V9tQMkoi+EjLp67PFZuUVcWFdX8Y1L6MVef 7CwVdfEZSHtoGadIFl+MwTMyAZEGlVg9XC02FrM0wb52AyCM7Yb5je3TB9Yh7y/K cUebCVAeok4evcgpt5U5P9sgW8KjncNzU97H+7cprxkpnWVFOyzDcoh43yWeKOy4 s2ZUxuSd =PKIy -----END PGP SIGNATURE----- --=-=-=--