From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.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 YMWGA7Y722FXcAEAgWs5BA (envelope-from ) for ; Sun, 09 Jan 2022 20:47:02 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id UDT9ALY722GBfQEA9RJhRA (envelope-from ) for ; Sun, 09 Jan 2022 20:47:02 +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 9C35B2E226 for ; Sun, 9 Jan 2022 20:47:01 +0100 (CET) Received: from localhost ([::1]:50780 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n6e9c-00045M-Nx for larch@yhetil.org; Sun, 09 Jan 2022 14:47:00 -0500 Received: from eggs.gnu.org ([209.51.188.92]:60172) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n6e7a-0002oa-93 for guix-devel@gnu.org; Sun, 09 Jan 2022 14:44:54 -0500 Received: from [2a00:1450:4864:20::341] (port=52948 helo=mail-wm1-x341.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n6e7Y-0002HX-75; Sun, 09 Jan 2022 14:44:53 -0500 Received: by mail-wm1-x341.google.com with SMTP id v123so7464405wme.2; Sun, 09 Jan 2022 11:44:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:subject:from:to:cc:date:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=ry3RXVJPEK8ufWTUBCpLjsBZlUqsPmJXIQIx4T9aUsw=; b=KADAw0yz6a+bim5JM/4I7ISS15ICnyW4IEf1a6B+H96wNuuJ/tvDPaI6poh/wjsi/f HXoxW+Fj2UHFfarj3Q0eWyGNfxh+wxzL94DhNCWRx4FK/c8RbyzbXJ2pjtXSViE/Mx/T MfEaG2VQNHVXb0IW0kn+JMb55k21+BIUmNBfo/FbmZ2lNNRBhi+ClcL+m7S/g3DtLpMS Pmpjgjl02umujUbj8vqrghhNbp860UgJ8GKCQMjB+LVhu8HyDJ+k/WE7KBeyg5Ui1jnL W609dY1R4DlTH+M8r9f6QgBZIs6xODEu5V3keX9s2DFD9B60+gIlghm7DVqeWHvMcxSL 2Hpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=ry3RXVJPEK8ufWTUBCpLjsBZlUqsPmJXIQIx4T9aUsw=; b=yClppvZ0+NOMx9hd8X8AVZ2WlNs3bd2eNK0nIYPy7ZzTGdptwtNi3pA5h7EZL8RLC6 jgT1vSjDcsnEO4XuHZUQaUhI03zxpo1bphsHTo2bxMVcdEUxyrTGqHkGHpebzzimg8M4 SPJYCl3D59xRQCucFdKjiRuoU/x9SiuvA7v/In9KFYYtMCkboZYMfJfVMIhcKxF7UAop hafTmlnEpPBawf5tg15d8QOajn7tUnyXyrgYxzWAJPBaMNmOk7zHem7tlaI5QP3F8al4 yOkdzv5OomEG3tqBWjllylL60QWxTXrXrumXN+qOlOk6q7pjdq7tgxyhQ67Gyj1bSy2P vaMQ== X-Gm-Message-State: AOAM530h3q4oE8KpDCCAhB+HzqD7EWq7tZLpEoHiA7r293WwS3/9JmnB lHGmpakhSsCNffiMFOTbNKg= X-Google-Smtp-Source: ABdhPJyhEIIfq0Sx4sRWlJgyxpEOj2jjQ+MMperWrjvdV9+KKwxIDAWE+ReyGYxOpczNljT8Tyw4Eg== X-Received: by 2002:a05:600c:3583:: with SMTP id p3mr19375919wmq.180.1641757488926; Sun, 09 Jan 2022 11:44:48 -0800 (PST) Received: from nijino.fritz.box (85-127-52-93.dsl.dynamic.surfer.at. [85.127.52.93]) by smtp.gmail.com with ESMTPSA id w18sm4802579wrs.26.2022.01.09.11.44.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 09 Jan 2022 11:44:48 -0800 (PST) Message-ID: <888e529cb04bb74bfd98f8e07db0c522efee9251.camel@gmail.com> Subject: Re: Return back original implementation for text-config serialization From: Liliana Marie Prikler To: Andrew Tropin , guix-devel@gnu.org, Oleg Pykhalov , Ludovic =?ISO-8859-1?Q?Court=E8s?= Date: Sun, 09 Jan 2022 20:44:46 +0100 In-Reply-To: <871r1g4x6e.fsf@trop.in> References: <878rvp1deg.fsf@trop.in> <871r1g4x6e.fsf@trop.in> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Host-Lookup-Failed: Reverse DNS lookup failed for 2a00:1450:4864:20::341 (failed) Received-SPF: pass client-ip=2a00:1450:4864:20::341; envelope-from=liliana.prikler@gmail.com; helo=mail-wm1-x341.google.com X-Spam_score_int: -7 X-Spam_score: -0.8 X-Spam_bar: / X-Spam_report: (-0.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-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=1641757621; 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:dkim-signature; bh=ry3RXVJPEK8ufWTUBCpLjsBZlUqsPmJXIQIx4T9aUsw=; b=LWrwPGgFN/QsfR42lk8T5QPoEUKXoFEfqsLF2ojzqAdMGh3XZYIwThtIt5JDRWxrE3yLLM 082k9nKezrda1k7cy1GmJ+Tj/WsWCmfdwu9HA9lldhcmMUg9kklxK0xsF9PxNNBGJXaIcw QVK80bKhEe9U0kbDFmlEPwIKiGO1NebnJY3JbfK2ALJVb+iMAQ7qC0bDkv54YE21x5ykBC zg18nz7bLsyC3qKqyd+7v8hxxJuCcFj3CMNaWNG1kM5Cyly7Tqi4Me1vEyxgGYUHUHqZEB J78jw0SiUj7rbc6GqtEh9jXYGj7MZJDx6gIYAYUkf9Zad8Mdii1Cte6nqhCQ/Q== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1641757621; a=rsa-sha256; cv=none; b=fOaiJ6vLGLobals3HT9Ujbk7kFbNA5zTzoSrxHSdlin3OF2jRjToTPXkpjZDKYbIgyDfb9 dNDvgDCNvTEWPnSGt2uG7Wa0pRiDvfDQF1AqY4l6AAbMhiCp7cYzX7IxXvR4pj7OoFBWFX ez67mDkjgawoNs70ZAcQZoeIZf+Jx0QfokcHA0/q6vSQ3DebLxxhlpChzs05fUVGl5mh5H J31SLyaQh0Eac/HVVVEkttOZgzxiagZToCsIfyXhkaE+exWI/f2yTx+QD1RNg7jHKE5uqK FCmnxqZVhzLv5sh1fItFBKIQE+svC9hYyF3LTEmu5rk9H5yCjyYu46BZFcUlsw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=KADAw0yz; dmarc=pass (policy=none) header.from=gmail.com; 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: -2.81 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=KADAw0yz; dmarc=pass (policy=none) header.from=gmail.com; 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: 9C35B2E226 X-Spam-Score: -2.81 X-Migadu-Scanner: scn1.migadu.com X-TUID: fijBpWTHZ+oN Hi, Am Sonntag, dem 09.01.2022 um 20:48 +0300 schrieb Andrew Tropin: > 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" > > >   ,#~"string valued gexp" > > >   "source \" > > >   ,(local-file "blabla.sh")) > > > --8<---------------cut here---------------end--------------->8--- > > > > > > would yield something like: > > > > > > --8<---------------cut here---------------start------------->8--- > > > string here > > > string valued gexp > > > source \ > > > /gnu/store/00fl96dj2aak4i1vqvdqzlhbmmskc7fx-blabla.sh > > > --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[.] > > 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 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.  Just missed > that importer already uses it. > > 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") >     (@ (ice-9 textual-ports) get-string-all)) > --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. 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. > > 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. 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. > read-everything-from-file is just a shorthand for > > --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))) > --8<---------------cut here---------------end--------------->8--- > > a gexp used in > https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services/configuration.scm?h=2c451db39aabc69bdbf186f412ee6e0b4e180ccb#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. 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. 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. 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. 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'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. Cheers