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 GDIIEsIH8WExPgEAgWs5BA (envelope-from ) for ; Wed, 26 Jan 2022 09:35:14 +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 4ItSD8IH8WEKWgAA9RJhRA (envelope-from ) for ; Wed, 26 Jan 2022 09:35:14 +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 6D3392C9EB for ; Wed, 26 Jan 2022 09:35:13 +0100 (CET) Received: from localhost ([::1]:57494 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nCdlo-00070p-GA for larch@yhetil.org; Wed, 26 Jan 2022 03:35:12 -0500 Received: from eggs.gnu.org ([209.51.188.92]:50488) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nCdlE-0006qe-PE for guix-devel@gnu.org; Wed, 26 Jan 2022 03:34:36 -0500 Received: from [2a00:1450:4864:20::12c] (port=44945 helo=mail-lf1-x12c.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nCdlA-0001NO-Rk for guix-devel@gnu.org; Wed, 26 Jan 2022 03:34:34 -0500 Received: by mail-lf1-x12c.google.com with SMTP id u14so30573623lfo.11 for ; Wed, 26 Jan 2022 00:34:30 -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=V6r2GJ4Gtg7J3EcQSfpedQthNgRPJQ4ki+d+IwKkUV4=; b=TzuVs6JE11yHhe8Ngz68dH393xhO9OqB0xxhZ3ImJRAWj3n88fQIV6AqII0JK33qst PVhH29e+E/AdA0t5gnENK3LD6RW30Bs0hMWFDirFIsv8gJXsDPLMPkUPX83DyDFO2IPp JcaUIVeTItE2vyHTaADO5X5OReHyRoy6tcAsDGtEgn7HBer7EHxMCluVk/zyduZeubf5 2UiQ00Oy1KyeT1Rw8WElC7Mh01Tr9HDyTO7Wp6KtQSzBwL46Dv1stRtJ2/dPSElc61Cl 5JyWXWa3bWx6U7Lzu8kT5jvDaFBXz32IZEZsCXb0CQOmdUaSovE+huRBYc0gr1mSUxJC 0E7A== 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=V6r2GJ4Gtg7J3EcQSfpedQthNgRPJQ4ki+d+IwKkUV4=; b=3UTMk6xc58QsPe9gkCMU4zULmYcFANOzvcKLzQ+e7dkkKkajh/jG0Z5bOGy7cKp2ew 2v15FnaTkc5Qboz2jn+LiAt00EMd4B1w+fvpGymBBMKai8Ell+gu6rMKbu5icDNa8yVu 7rcVT0LWao95lxIjiqqR1KiYLHMfZ7jxi+9ktzMDv7LaMD1HiSH/y6/fSZhLsayddU1N SMzAevNBNFO0TyIFBC/I61aqOV5F3hsYojO+yHJA6FkkUmmlvjOlpAkXD9YkvNo6vJ4+ 7LDx53fy96bQPKtCOcyZau/weVZcCQhXU383QC/ty6KmKuQ/wE8D04e9aR1oMLf4YujL ptyA== X-Gm-Message-State: AOAM530VYGLLetHegUnMLRCNch/bGUqh6WpfPIyX8uyngpNwRB+6UD6h aKYnG6QMW6VMdHo7kN0JhtS61A== X-Google-Smtp-Source: ABdhPJyWPf84li9DPRuz0AcFpDe/fDiTPR85ZCEzFRzHYy+ECf+9HEe5y3PycPGOZO0EsRkZudvDLw== X-Received: by 2002:a05:6512:2809:: with SMTP id cf9mr6390197lfb.209.1643186069213; Wed, 26 Jan 2022 00:34:29 -0800 (PST) Received: from localhost (109-252-135-33.dynamic.spd-mgts.ru. [109.252.135.33]) by smtp.gmail.com with ESMTPSA id q16sm1744901lfg.170.2022.01.26.00.34.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 26 Jan 2022 00:34:28 -0800 (PST) From: Andrew Tropin To: Maxime Devos , Ludovic =?utf-8?Q?Court=C3=A8s?= Subject: Re: Return back original implementation for text-config serialization In-Reply-To: <405630188ac22fd2a1f1d0e0555ce061584744a3.camel@telenet.be> References: <878rvp1deg.fsf@trop.in> <87mtjtglxd.fsf@gnu.org> <87o846y24v.fsf@trop.in> <405630188ac22fd2a1f1d0e0555ce061584744a3.camel@telenet.be> Date: Wed, 26 Jan 2022 11:34:24 +0300 Message-ID: <87h79qx5db.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::12c (failed) Received-SPF: none client-ip=2a00:1450:4864:20::12c; envelope-from=andrew@trop.in; helo=mail-lf1-x12c.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, PDS_HP_HELO_NORDNS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URI_NOVOWEL=0.5, WEIRD_PORT=0.001 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=1643186113; 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=V6r2GJ4Gtg7J3EcQSfpedQthNgRPJQ4ki+d+IwKkUV4=; b=KjpYkR47KY8s6yF64hxaVMm5LPvLP80nmXT+vQOLU5jlmd/vYrS7KqxtvaH2BMJFphLIso CgDhvgqjsVqWUwSOf4MW34Ru9Inh+rQ3q2af+isRf9CJqHP/HWKSOJdWTxzpC6F8hGGB1c 5M19Saxagot0gedS3IyY6TXISpXFKNK/btfUc+KCtF2bNkpSZ7BSxStoIwneJGjEoTcBXr USTff74i1+8322+rDFHA290gd5n6QJUZkkaTfkvICMuxrMz369v3sT3qw2rYft2s39ebzP +vEjjWyKV2rYP+s0Zwbayn9c02e7omGNEDF5+tKXAsr/ePGwobZHA96cBGiShA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1643186113; a=rsa-sha256; cv=none; b=C0wiS5GwP9lD68ttEoiP+YAMegr6qdtbEB7bsTR6evzUZPa/4156d9NxE5+gF9mpaw6c8Z m0wfNGaJxzIfSTHtwKH7JD2yKXsdX5MqJ9Nix+lFTbucwzZRuXJbYyEwbeyA0nvc9xM/y5 R/NWesus0QbLSE5nPHLbOWHVeGaHi1JAWitvBAIoA2BvuFNkHlesCKvf5ZlmwiGmT6YTS6 SqS8+3H10jj31C63BOUKqSe91tTgQ3MJx8QV9v2mFfuYJ7ay10xKQHpKj5kdjPqJaig/Ny lgdSv83B5pGiNNi//LUCSKzuPnoO4Rjtei3wBbcIrFUmUFlTcE5cUCwlfV4SJw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=trop-in.20210112.gappssmtp.com header.s=20210112 header.b=TzuVs6JE; 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.93 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=trop-in.20210112.gappssmtp.com header.s=20210112 header.b=TzuVs6JE; 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: 6D3392C9EB X-Spam-Score: -5.93 X-Migadu-Scanner: scn1.migadu.com X-TUID: fy/OOBwUfSMb --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2022-01-21 10:30, Maxime Devos wrote: > 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)), Possible, but not really necessary I think it will be ok to just use: (mixed-text-file "" "source " file-like) It looks like a light missuse of file like objects because we have to specify "" file name each time, nothing critical, but still feels a little wierd. > > 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 concatenated-file is not needed, we already can use source-file and mixed-text-file directly in bash-home-configuration: (bashrc (list (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=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=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. The G-expression, which slurps the file. It's just a funny name I borrowed from Clojure: https://clojuredocs.org/clojure.core/slurp It was just WIP name, I don't mind naming it differently. > Also, we already have 'mixed-text-file', so maybe we can create > an =E2=80=98concatenated-file'? Yes, I was missing it a few times, when I started to use guix services a year ago. Current implementation of text-config do a similar thing, but it would be cool to have a separate helper function independent from guix services. > > (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. Not a big deal I think. Optionally, we can support strings, so it will work as a mixed-text-file, but will be inserting the content of the file instead of the path, however it can be a little confusing. > > * 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 th= is > 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. Very good you rised this question. Discoverability is true, with records it's a little easier to get tips from geiser, however, the safety provided by this weak type system is almost illusory, also, the same degree of type correctness can be achieved without records. IIRC, I covered this tradeoff in Writing Service Configuration manual section: https://issues.guix.gnu.org/52698 > > 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. Having extra-content basically says that we give up on implementing a proper serialization and user have to use a mix of target configuration format placed inside a string, which must be escaped of course + lisp-flavored version of the same configuration. I have an excerpt of very simple real-world nginx configuration, which still demonstrate the idea: =2D-8<---------------cut here---------------start------------->8--- (nginx-configuration (modules (list (file-append nginx-rtmp-module "\ /etc/nginx/modules/ngx_rtmp_module.so"))) (extra-content (format #f "\ } rtmp { server { listen 1935; chunk_size 4096; application live { live on; record off; push rtmp://a.rtmp.youtube.com/live2/~a; push rtmp://diode.zone:1935/live/~a; } } " youtube-key peertube-key)) ;; WARNING: secrets goes to the store. (server-blocks (list (nginx-server-configuration (server-name `(,ip)) (listen '("8088")) (root "/var/www/")))))) =2D-8<---------------cut here---------------end--------------->8--- In addition to the problems I mentioned above: 1. Mixed usage of two configuration languages (nginx-conf and lisp). 2. Having a string, which should be properly escaped (luckily for this example it's not a problem). we also: 3. Have to implement our own templating engine (using format function in this case) to share the values from guile with the config. 4.1. Don't know where extra-content goes. (It goes to http section not the end of the file, so we have to start with "}" to get a correct configuration). 4.2. Don't control where it must be placed. (Can be important in other use cases, which I can share if needed). 5. Have inconsistent implementation of extra-config, extra-content, raw-lin= es and other escape hatches (We need to learn it everytime we write a new service configuration). but it could be: =2D-8<---------------cut here---------------start------------->8--- (nginx-configuration (config `((load_module ,(file-append nginx-rtmp-module "\ /etc/nginx/modules/ngx_rtmp_module.so")) (http ((server ((listen 8088) (server_name ,ip) (root "/var/www") (index "index.html"))))) (rtmp ((server ((listen 1935) (chunk_size 4096) (application live ((push ,(string-append "rtmp://a.rtmp.youtube.com/live2/" youtube-= key)) (push ,(string-append "rtmp://diode.zone:1935/live/" peertube-key= )) (live on) (record off)))))))))) =2D-8<---------------cut here---------------end--------------->8--- Ludovic mentioned someday that nginx-configuration is problematic, but I highlighted the generic problems, which are applicable for many other guix service configurations. I discussed some other pros and cons of record-based configurations in https://issues.guix.gnu.org/52698 and I see the benifits of the records, but I'm not sure if they outweight the weaknesses. It maybe sound unrelated to this thread, but it's actually very ontopic, because it lead to the design and implementation of home services configuration approach in general and slurp-file-gexp and text-config in particular. =2D-=20 Best regards, Andrew Tropin --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJDBAEBCgAtFiEEKEGaxlA4dEDH6S/6IgjSCVjB3rAFAmHxB5APHGFuZHJld0B0 cm9wLmluAAoJECII0glYwd6w39EP/3S1tUEpnul5tyZ7iKEESu8gMkfw0Homl3/1 55P4cIpNGWJ49UHiDvavz9K21F9TCq3oeUqoAf3FnK7WIucMb2vLGjzqvFHTyBEJ SEZMLFSSgV6xwAfUl/DZwqLvqgfccmR00u1Bl5jpBQVutcQRmcO3M/YTReD8Rl19 nEUqlNc0XYGANi2+NKt22tsUqi8TI3YSXlQ9A7b4GOteTKtSKtECgMwYi/H/FDAl IxednFVJb/AejWx05fy/3LnXCK+SxD2JSoDsROC3mAKnOQC1f9VrZ7RocN4tCNHR d9OHnbIyoFM+6jKN3oOCnIQMXS0CRiRtvoak3aGjxkYzxVMCDnYZhGHdfeXDTxdY UJaC+6Me7p0d64ae/DXFF/edydamaSwjImY/XSkgCs9UC5sv98IMpVS7NMWJ5rVB Lx7XquaIJ7y6sHIEpAFQAWeLsb5083rfP1LuRSUnLB4cuUVM1PPxAJ4X/6EAaAw2 6XdzMrgpLXULqrnL8uW/oZjIOpLKyOUv3/wxIQBUxR9B6/msDf2EPuUQrkrY+pJ8 Y0X8n0uWnsef+E4cbOzKxX3cwVfkAop5/e+bqryFYm/PL4hFoSY15LdPfeaZFFZe WmPvVR9hMP7f6OemLItZ6tNdy6Is3kMLRgQarc2ke3962GcrEi29g8GhW+zR8QzF +xUGKXYe =LwBW -----END PGP SIGNATURE----- --=-=-=--