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 +KmgCE4I8WGrXgEAgWs5BA (envelope-from ) for ; Wed, 26 Jan 2022 09:37:34 +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 WOT5BU4I8WEKWgAA9RJhRA (envelope-from ) for ; Wed, 26 Jan 2022 09:37:34 +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 B69872CBBA for ; Wed, 26 Jan 2022 09:37:33 +0100 (CET) Received: from localhost ([::1]:59020 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nCdo4-0000Mu-Rc for larch@yhetil.org; Wed, 26 Jan 2022 03:37:32 -0500 Received: from eggs.gnu.org ([209.51.188.92]:50958) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nCdn7-0000Ln-3K for guix-devel@gnu.org; Wed, 26 Jan 2022 03:36:33 -0500 Received: from [2a00:1450:4864:20::129] (port=46902 helo=mail-lf1-x129.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nCdmr-0001qK-11 for guix-devel@gnu.org; Wed, 26 Jan 2022 03:36:22 -0500 Received: by mail-lf1-x129.google.com with SMTP id z19so24907795lfq.13 for ; Wed, 26 Jan 2022 00:36:16 -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=Z8qoT8q0g29Z41Z6qOsthh+MkVMqaXt98+ydUS3yNdk=; b=pY92lxDTS61fqvaIXx8yol/CgHlZQFHOb+60RlFt5Am6UDUIih9oiWFjxI+RUb7jwX jZeMH8MQegWKUGVRRxrY6JXO9MFM1AUbT2EKbMiibLnjqXhgt6eb9XQBYTaMVr8vDdu6 1QXZZPZQAnkkXYDFRrAly+QFrCi5buD0K+14UVW8c3E/oUJOrdC4sTsHpng9gLGv4IK0 aJpq50brlXLFpbHOfilpWjCrVxlv5otNbJ3vL5lVNsxb5ccU6LXMBGwxlaQv9LhHj+dy CBVmucodgPRM0iJzJcVT40KjIcmF59rfP631CcjuazUiPqohk6fWpuyWtrrsxbfW4AFb 0JVQ== 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=Z8qoT8q0g29Z41Z6qOsthh+MkVMqaXt98+ydUS3yNdk=; b=Ri7EfYZQyvAWt7dVyB2CgCXs1qID3QHlXzv8FTYQ2x60GcqLw6d13oqiKTZFIM7yTy O0VwWkdd0q6LssYpJ9lo/td8s1rAyaXZLU33pK5UXTuKkpsjKe0NPHbm2mwedUY3l+sf uhyXbxRtPEcodIEb+ydEtUEeNL9KbmLsJ1wJyi0O6v+3L3bDC+GYp/DyToIqWq/ug9a0 0G3q83AcDefbfLEOF2016e2THwAlHLMdTsosOU7ruZTipiRJWMBEBjvNyxItaPHJyEm9 mHM2S4YhHBQZ6sTM29B8lrVR4Gb7WKsAWepu2NwEbbzdCHcNNB3jxNqFdEQ7XrxJ1ZLo g2Jg== X-Gm-Message-State: AOAM531PbwBlVsGvL3eWLTUi397jsb1WpPstbdh6ltks0VKlCWoRHjIe JkpUPqQsCc4wo+HX/cmn/l8tZA== X-Google-Smtp-Source: ABdhPJzXjuRdfsbcuCsqIUmqUtvHJSxWXOphOqf9ERVQvqQHOgYRGCjKHd2xi8tLnxN9Iq2XfzfjYw== X-Received: by 2002:ac2:4159:: with SMTP id c25mr14575583lfi.250.1643186175407; Wed, 26 Jan 2022 00:36:15 -0800 (PST) Received: from localhost (109-252-135-33.dynamic.spd-mgts.ru. [109.252.135.33]) by smtp.gmail.com with ESMTPSA id z8sm173874ljn.89.2022.01.26.00.36.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 26 Jan 2022 00:36:14 -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:36:11 +0300 Message-ID: <87fspax5ac.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::129 (failed) Received-SPF: none client-ip=2a00:1450:4864:20::129; envelope-from=andrew@trop.in; helo=mail-lf1-x129.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=1643186253; 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=Z8qoT8q0g29Z41Z6qOsthh+MkVMqaXt98+ydUS3yNdk=; b=N88je84XPaqNQ+L9bBsP2KFa05cbqBF6jSbG5yezTipazrkIMrzfaUg3nwUAXArbQxQG9t E3qLazXeFWFHf5mSk/NOXQRukF0Lt4wOUZLLF8Ubfoxdzcyi+n2t/J7XWi36xypdTMFRSd JYsLg67fzlB1OWfUfdiwJD2e/NjeHhIP77gj2WQUf5w8LB1GGgBtkwqQVvb5tZuASswEni TYrCakSYTWhcoJ5T1N6A50dey7L9Z1tqvREUzA8ygh/Q32po1G1yUbTWepuUEVdODeWeUn oBWj9HXUAw/p92eOEjBsPHq/uXC1oou4eDvmfB9hSea0x0pmKNIBES0MBYzR/w== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1643186253; a=rsa-sha256; cv=none; b=bDb3UfLwXpBBWfpIWQGIJKfnN0ScnUOay8R2uy1VMaq04HFJ0M60fMeohh5xXvBrT27zQL +BA4BSbfZr8XdAuFscbGp5A5RSMFeL/xzDdBdD0bdkV8TgpB6IkM8OTCYWQh918O3wFGrp yBu6SvRPTMMTlMQ1aMu+ifuzHjmcfAYGdhl5eInxSyQ8paTSgfumMRTLZk/2OhrY8hv4s4 OK+Q5w2YedOm4p/SeXJfQ2W2ig6zpfVhhSdwormhc3fQ6+rUh33lAETX6rzrj5M5pQO/va ZNYLcYUU2Tj+YjPYwcGitkHhDDjmB2Tf/a6vKrnOUy/NdCQX+gVrdrChnbvASQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=trop-in.20210112.gappssmtp.com header.s=20210112 header.b=pY92lxDT; 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: -8.23 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=trop-in.20210112.gappssmtp.com header.s=20210112 header.b=pY92lxDT; 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: B69872CBBA X-Spam-Score: -8.23 X-Migadu-Scanner: scn0.migadu.com X-TUID: gjrG1pI7whWw --=-=-= 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/6IgjSCVjB3rAFAmHxB/sPHGFuZHJld0B0 cm9wLmluAAoJECII0glYwd6wLxsP/391lmDGTRP0XxDQtMjf33Wz7ucntG3halbz /xrN3hFBsT0zNt6vte/9XrZH6idjXBL8UY0p1UVQOPjg8mynP7R52nJAgeymIEh5 28WGy/VN6673nIXEMFEzvcfo5XYbBHCD24vKt1omFXHPHotonGVqwKKlvhXep4mX qtedMJgEdhJ5zoE1z6d5vg+2ONo7LQDfqCiS8HHfJ9R3cF1Cq9z+gAJctclB8txw QtEb+j00/CoeluUsayzIEfRFEz76e39/qZH6h07lCRLvo3I8QNP4JKCrZ2nVvtar G62mracxoffGPcLa7xqbbO/XVU1gqN92EC4rXxVrc6IlDg4Xmqd+9RrQ/9fUytB2 gR+eNXG3PlD0dtEZoUFlp8ZXSEjRk14OtaJJmS+FQwt/Br87/QkYQyK18YtudKl1 wLPafPimrygW/cfZc/V8eusj0mJGfdL+t+sMc00nhJ1noZbREemhqbd3VZ0U1AiL o/+vo2NJ8G3f/aMGgVPD/KZXbMa0qOTCtc8Z5OjC2Qt14Xb7BADhtD4DhGc/RX3x 1olspToJKdOv9AbZkbaqhy7IJQUw9jg/an2rvWxcyFOn/HfQMZpS6hVejVZ/W8Uk GiqE8tfhLFXgYkCymg46H3O1Y5l2YewvVxXQDNjfsZwckRZkJoZs5mcCDRbupRic fxe7y6wS =xMhe -----END PGP SIGNATURE----- --=-=-=--