From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.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 mEUwEMN96mHs1gAAgWs5BA (envelope-from ) for ; Fri, 21 Jan 2022 10:32:51 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id cAn2CMN96mE7KAEAG6o9tA (envelope-from ) for ; Fri, 21 Jan 2022 10:32:51 +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 BC1E02AF1F for ; Fri, 21 Jan 2022 10:32:50 +0100 (CET) Received: from localhost ([::1]:33754 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nAqHp-0007E3-Oy for larch@yhetil.org; Fri, 21 Jan 2022 04:32:49 -0500 Received: from eggs.gnu.org ([209.51.188.92]:34730) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nAqFS-0007Bd-Np for guix-devel@gnu.org; Fri, 21 Jan 2022 04:30:25 -0500 Received: from [2a02:1800:110:4::f00:19] (port=46412 helo=laurent.telenet-ops.be) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nAqFK-0003do-O6 for guix-devel@gnu.org; Fri, 21 Jan 2022 04:30:16 -0500 Received: from ptr-bvsjgyhxw7psv60dyze.18120a2.ip6.access.telenet.be ([IPv6:2a02:1811:8c09:9d00:3c5f:2eff:feb0:ba5a]) by laurent.telenet-ops.be with bizsmtp id lMWA2600d4UW6Th01MWArK; Fri, 21 Jan 2022 10:30:11 +0100 Message-ID: <405630188ac22fd2a1f1d0e0555ce061584744a3.camel@telenet.be> Subject: Re: Return back original implementation for text-config serialization From: Maxime Devos To: Andrew Tropin , Ludovic =?ISO-8859-1?Q?Court=E8s?= Date: Fri, 21 Jan 2022 10:30:00 +0100 In-Reply-To: <87o846y24v.fsf@trop.in> References: <878rvp1deg.fsf@trop.in> <87mtjtglxd.fsf@gnu.org> <87o846y24v.fsf@trop.in> Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-+2O5DIAWN9R1ce+BoPrz" User-Agent: Evolution 3.38.3-1 MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r22; t=1642757411; bh=f9U3ppf1FouaK5sc9tu983aTByvtZLKdrv4OAGKbdUE=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=MnXzxDtKefDjlIGcLkKgHfBIGhTS+STh3rTy2ZGxis0YS4NneLoyIJZFPQZT7OD7M yo/ryB8y9pypQQK1NZ/UDhCeBD7ll6SnanPDZxArEmCM2kwlmnu83q6f6WewE3J8FJ CrFtZMzVCG8ziZ4k0wFG+9RAIQP7gfyasq7+WGJbUFDz9uINPB25D84hoEpks/U9Jb LonWbJ69e8h2qvCPcx1OjRZxrCGALY/9CfIvPTJA6b7yEOncrwUlWgpOAC46f6fj3M GJNm+Rnj70Eq7k66Lna61yiAVxs4nOLcbwvlKGpxGxqstK/pLDDU3Pm9oR1bPHOJ3a RE/ePczOpe8yg== X-Host-Lookup-Failed: Reverse DNS lookup failed for 2a02:1800:110:4::f00:19 (failed) Received-SPF: pass client-ip=2a02:1800:110:4::f00:19; envelope-from=maximedevos@telenet.be; helo=laurent.telenet-ops.be X-Spam_score_int: -14 X-Spam_score: -1.5 X-Spam_bar: - X-Spam_report: (-1.5 / 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_LOW=-0.7, 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: 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=1642757570; 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=f9U3ppf1FouaK5sc9tu983aTByvtZLKdrv4OAGKbdUE=; b=o2d1yz7C+BYzSuFJXh+89OIRkwtFYHhAswlCBcS0hj25gZflpvlIOmeHzBHJ4LoxVUCx/i N2IADhcm5ZXofjDUIQphxek4oQqGdH6fz1ylXczaMtPSNRYa804h45qEPKXTWp8l0LtEOK v2C5rlC9oOuT2fUzOAzcQRA52XzQaxV109YzqnyacSULWSs1PtpB/QTS4CaoZsiShWgoMS 0/doLiAb4usDaS4n7RVJba2d6W596LpKuKsTc6FJkUmp50uZzXVbPfqv5UXe+UIceSuBE3 NaEyvmugudo8dnOnQn980V+ajKpNoGltRICXO/n95qP27T1gxuTe68kRITuOzg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1642757570; a=rsa-sha256; cv=none; b=kYXAI1UEvNItXj5VliuK45+Z2kLJxbHYQtS+oi1SYAu9hbdycJMD/622HhUpxK7fcd8DJr A11fnVMQagb5vrwKYU+i7hAlIa0BYEQH51A4rsucevmybb3QZ0EB9Lc6so47ISvP3jv6R2 +H0ZYl0zPX3z9tdb/Al95dIXF7bvT/tDDAmcOgZE6hSTRTJMq8lFl9fWbDStY8lK7mtaCM 6O9bUaKbJt15AVtgK9XGf6ZaFhHjZbu6LXaxcFoW9jLVv/Ku5FBSazxuTMUYn/daRSWE+u s642sEAn5H7EuU32W8jphUmBkrea3sJH7QiiLQOEIjnAkSuNUJUPQEaik4nKeQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=telenet.be header.s=r22 header.b=MnXzxDtK; dmarc=pass (policy=none) header.from=telenet.be; 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: -11.42 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=telenet.be header.s=r22 header.b=MnXzxDtK; dmarc=pass (policy=none) header.from=telenet.be; 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: BC1E02AF1F X-Spam-Score: -11.42 X-Migadu-Scanner: scn0.migadu.com X-TUID: bgfHpP295bMR --=-+2O5DIAWN9R1ce+BoPrz Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Andrew Tropin schreef op do 20-01-2022 om 16:20 [+0300]: > [...] >=20 > From what 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. To be clear: * >> source \ >> /gnu/store/00fl96dj2aak4i1vqvdqzlhbmmskc7fx-blabla.sh How about defining a procedure (define (source-file file-like) (mixed-text-file "source " file-like)), the 'concatenated-file' described below, and giving an example or two in the manual on how to use it? (concatenated-file "" (source-file (local-file "some-bash-functions.sh")) (mixed-text-file "" (file-append coreutils "/bin/echo") "hello Guix Home!) "\n" "invoke-some-function" "argument"))=20 * I don't like 'slurp-file-gexp' (what are G-exps doing there, and what's slurping?). A better name would improve things though. Also, we already have 'mixed-text-file', so maybe we can create an =E2=80=98concatenated-file'? (appended-file name (plain-file "" "foo") (local-file "bar")) --> foo A slight downside is that the plain-file needs to be given a name, in this case "", as you have noted for 'mixed-text-file', but that can be avoided to a degree by giving it "" as name. * IIUC, the reason why 'slurp-file-gexp' or the like was necessary, was because the implementation doesn't use records for configuration, but rather some mixture of S-exps and =E2=80=98copy this and that file is the serialisation here and there=E2=80=99. I would prefer not using S-exps like (home-service barfoo-service-type (barfoo-configuration (config `((this-option "that") (foo (bar z) (foobar (include ,(local-file ...))))))) and instead write these 'this-option', 'foo', 'bar' and 'foobar' in records, such that there's to some degree a type system and some discoverability. Yes, if there's a lot of options that can be configured, then initially Guix won't support all, but it should be easy to patch Guix to support more options on an as-needed basis. There can also be an 'extra-content' escape hatch. For software that doesn't support inclusion directives in configuration, we could: 1. patch upstream to support it (it's free software and it's potentially useful outside Guix, so why not?) 2. or do something like 'concatenated-file' with a preference for (1). As such, I'm not exactly agreeing, since there appear to be better options than 'slurp-file-gexp'. Renaming 'slurp-file-gexp' to something more descriptive would help, but there's more that could be done. Greetings, Maxime. --=-+2O5DIAWN9R1ce+BoPrz Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYep9GBccbWF4aW1lZGV2 b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7o/NAQDC8Za0ayW4Afa29kv8g+U8Puib SyC5h3vhK4YZEOvPKQEA6DPbbB9mW4zES32oVLaLUY5Pa8fcXBbEzJaCNfrqiAw= =w1Vz -----END PGP SIGNATURE----- --=-+2O5DIAWN9R1ce+BoPrz--