From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id gBthF9NcXWEREAEAgWs5BA (envelope-from ) for ; Wed, 06 Oct 2021 10:22:43 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id qB4rE9NcXWGVBAAA1q6Kng (envelope-from ) for ; Wed, 06 Oct 2021 08:22:43 +0000 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 D19B812EB5 for ; Wed, 6 Oct 2021 10:22:41 +0200 (CEST) Received: from localhost ([::1]:50314 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mY2CG-0000H8-Vf for larch@yhetil.org; Wed, 06 Oct 2021 04:22:41 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:55858) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mY25q-0001VA-M7 for guix-patches@gnu.org; Wed, 06 Oct 2021 04:16:03 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:59102) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mY25q-0001cC-E1 for guix-patches@gnu.org; Wed, 06 Oct 2021 04:16:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mY25q-000341-8w for guix-patches@gnu.org; Wed, 06 Oct 2021 04:16:02 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#50967] file-like objects instead of gexps Resent-From: Andrew Tropin Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Wed, 06 Oct 2021 08:16:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50967 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: To: Ludovic =?UTF-8?Q?Court=C3=A8s?= , Xinglu Chen Cc: Oleg Pykhalov , 50967@debbugs.gnu.org Received: via spool by 50967-submit@debbugs.gnu.org id=B50967.163350815011753 (code B ref 50967); Wed, 06 Oct 2021 08:16:02 +0000 Received: (at 50967) by debbugs.gnu.org; 6 Oct 2021 08:15:50 +0000 Received: from localhost ([127.0.0.1]:42415 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mY25a-00033S-Js for submit@debbugs.gnu.org; Wed, 06 Oct 2021 04:15:50 -0400 Received: from mail-lf1-f45.google.com ([209.85.167.45]:33504) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mY25W-000334-IH for 50967@debbugs.gnu.org; Wed, 06 Oct 2021 04:15:45 -0400 Received: by mail-lf1-f45.google.com with SMTP id y23so7201738lfb.0 for <50967@debbugs.gnu.org>; Wed, 06 Oct 2021 01:15:42 -0700 (PDT) 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=k85SnflNA0PbJjhiINOSyxq4xuwxVOak2hfVozOw+KA=; b=GBqG26hmf7bDR+O1ouRNSjWKifI8gFiO87apkeanOtSagX9TEJqx43qljgSIsSgXC9 +tEXXv745bxfzUWcBIweyqODvA8WT2/YTweqZ/SEoJDYi7bFH2eR9+YP0ljDS9QgricO gl4Ry5q3ZpLbIouV5ahzpfyiju3Jwurk6bVEQHqcNpp0P1S2tp6qfq00o0lm4WmK25gX lQLQmzXXxyou+tLDjvalR0CnGQJCZchUtVdQMUQhJ1+xcuZWYCx8tjNfqDd9Vj11r5/j jo25Qr5IN2WgRO3Zq5ljo6fhyekZz1Kc2QRsP9wxXfD6uAIXrY1kChl453k1IotJSgDK 94PA== 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=k85SnflNA0PbJjhiINOSyxq4xuwxVOak2hfVozOw+KA=; b=K0y8VoJSl7d+jo7WRvw1y3kYsnYQnl1JXSoX2SNK2H4q+TYdkTWzrDM/Vp6IC+ENSS JV9kYFEGjF20Kx38VA4TB0e833tH4n0WcPV/ZnsxKvdHp+YE9eXY0ghKFWd2DoP2SbIP BiNuvpshGafR4EIFrmHs5vxFDIQenMZTL79mbyxbisRqc3MLpQxSl1HnoClV2TrxCbCv w8JAoNuz3QxeDPE3BsgFZvmIEOx4fgyCm3bzNOoWaYiolGwzKEtPEVHts0rDTEnm6wyY rRqlPwoRXvaMG7dtPT+iZxpPJ2R/qwoQPe2X9c5XTRo4e1hloo2OXWUUl49waYQO3Y+H BjkA== X-Gm-Message-State: AOAM530WBJF8FGngvZmELqCzkP6u17gW1uGpBDyUooUZtqyMAbJ1yEwm E/wD/XoLlD07Ake+aHO8ZngnOw== X-Google-Smtp-Source: ABdhPJzJM/GR5zWxMhozZIuVF1+AX46ztBpH5hZuetFalOAL6wCfJdkI7Eron0ecY6wMS+G9j3fq6g== X-Received: by 2002:a19:f249:: with SMTP id d9mr8415449lfk.229.1633508136492; Wed, 06 Oct 2021 01:15:36 -0700 (PDT) Received: from localhost (109-252-140-132.dynamic.spd-mgts.ru. [109.252.140.132]) by smtp.gmail.com with ESMTPSA id t13sm1368829lfc.34.2021.10.06.01.15.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Oct 2021 01:15:35 -0700 (PDT) From: Andrew Tropin In-Reply-To: <878rz8q42z.fsf_-_@gnu.org> References: <20211002163834.29583-1-go.wigust@gmail.com> <20211002163834.29583-13-go.wigust@gmail.com> <87pmsnnukj.fsf@yoctocell.xyz> <878rz8q42z.fsf_-_@gnu.org> Date: Wed, 06 Oct 2021 11:15:31 +0300 Message-ID: <87czoilgbg.fsf@trop.in> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: "Guix-patches" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1633508562; 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:resent-cc:resent-from:resent-sender: resent-message-id:in-reply-to:in-reply-to:references:references: list-id:list-help:list-unsubscribe:list-subscribe:list-post: dkim-signature; bh=k85SnflNA0PbJjhiINOSyxq4xuwxVOak2hfVozOw+KA=; b=bFJB6wWLvCME+GLf+I/ruMl4h1G2vUpqrQrllOZa7tdIxICNqDOfIdPl+/1aXsXSidVRA2 GFWIIYZbfI6P0czfCZLvuH/QhD5AS2f9lsA00pAz5yYdjPi98z2pbWS/P+be2O7nnuIiZQ 5CW7ARfp/ihY/WuUITeeD/vbPNkJsx5kgVVn8c2oSJ6jQTAXohZtJyFUHnQRfLQ8zH9uKt wnnDU1sLXJ9hHVEF466IfFrkFdMuQoOOBm/NFmKxolFmf4LXehhm4xL7aaj9t3T/7VpbXP Pldb8LHukeNhmvAnEyf/lkaqYUoiBqsDeD30g0L38X/sJWv52IdFumT03GO4TQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1633508562; a=rsa-sha256; cv=none; b=cCytnLLOiV/Yr8Y7Vxo3SsJbGKvPtlCjUkRRyuwzOEnNOkRLiVSwFI1GdZfCqVkW0G043p dBzoPCaQSiu/ssMQQItpIm/v2dGk1nPAPitXd1vdIEg+rSQ8ApCdBPVqpr+Ky3tnL6dL2V nfTutqv5nLRoI6IfU5dpmXxTwRWcbh49suvR3rSm8/DYmdJK3OXXhGKmOkNTJdbm5tZQeY tKhp1/rh9bhpSfDg1iL8CsgvV1i0hGAUg4Vc4XTZ51B47VWUobMXU8fSA3dvTNdYTStGbi gJf2ytiHSBYIxKmYYdGdgOZ9hlD8CBbJg8weE87hVqpN2jFEOO3bhO9wIz4DIA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=trop-in.20210112.gappssmtp.com header.s=20210112 header.b=GBqG26hm; spf=pass (aspmx1.migadu.com: domain of guix-patches-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-patches-bounces@gnu.org X-Migadu-Spam-Score: -2.01 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=trop-in.20210112.gappssmtp.com header.s=20210112 header.b=GBqG26hm; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-patches-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-patches-bounces@gnu.org X-Migadu-Queue-Id: D19B812EB5 X-Spam-Score: -2.01 X-Migadu-Scanner: scn0.migadu.com X-TUID: XxtBlcMw+GSz --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2021-10-04 16:04, Ludovic Court=C3=A8s wrote: > Xinglu Chen skribis: > >> On Sat, Oct 02 2021, Oleg Pykhalov wrote: >> >>> * gnu/home/services/configuration.scm (interpose): Include content of f= iles. >>> (string-or-gexp?): Rename to 'file-or-string-or-gexp?' and check for fi= le-like >>> object. >> >> I would call it =E2=80=98file-like-or-string-or-gexp?=E2=80=99, just =E2= =80=98files=E2=80=99 doesn=E2=80=99t >> really make it clear that it should be a =E2=80=9Cfile-like object=E2=80= =9D. > > As a matter of API, I would make it monomorphic: accept a file-like > object, period. This is what=E2=80=99s done for System services (and > polymorphic APIs are rare in general in Guix). At least some of system services are far from ideal, recently I tried to add rtmp section to nginx configuration using nginx system service. I had two options and both does look hacky, I could use extra-content starting with closing curly bracket: =2D-8<---------------cut here---------------start------------->8--- (service nginx-service-type (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)) (server-blocks (list (nginx-server-configuration ;; (locations ;; (list ;; (nginx-location-configuration ;; (uri "/stat") ;; (body '("rtmp_stat all;" ;; "rtmp_stat_stylesheet stat.xsl;"))))) (server-name `(,ip)) (listen '("8088")) (root "/var/www/")))))) =2D-8<---------------cut here---------------end--------------->8--- or use file field of nginx-configuration record and generate the whole configuration myself inside computed-file, loosing all the benifits of other nginx-configuration fields. Personally, I don't find both of these approaches appealing and convenient. Maybe it's an issue of exact system service, but the way the configuration for this service is implemented is getting in the way of the user. > > =E2=80=98plain-file=E2=80=99 and =E2=80=98scheme-file=E2=80=99 allow user= s to =E2=80=9Cconvert=E2=80=9D a string or a > gexp into a file-like object. > > WDYT? > > Ludo=E2=80=99. > > > Imagine the following use case: I want to create a home service, which accepts a package (zsh plugin) and adds a code for loading this package to zshrc, currently it's implemented like that: https://git.sr.ht/~abcdw/rde/tree/69dd2baf0384c899a4a4f97bdac8bf0b6e499b82/= item/gnu/home-services/shellutils.scm#L18 Exteding the service above with `(list zsh-autosuggestions)` will add the following line to zshrc: source /gnu/store/w7d43gk1qszplj9i0rkzqvzz6kp88qfm-zsh-autosuggestions-0.7.= 0/share/zsh/plugins/zsh-autosuggestions/zsh-autosuggestions.zsh Or the same thing can be done manually by user: =2D-8<---------------cut here---------------start------------->8--- (service home-zsh-service-type (home-zsh-configuration (zshrc (list #~(string-append "source " #$zsh-autosuggestions "/share/zs../..ions.zs= h") ;; or "source \\" (file-append zsh-autosuggestions "/share/zs../..ions.zsh"))))) =2D-8<---------------cut here---------------end--------------->8--- gexps returns a string, file-like object returns a path to the file in the store, kinda expected behavior. Both implementations looks quite simple. Now I'll try to reimplement it with file-like objects. The code below is a pseudo code, but should demonstrate the overall concerns I have: =2D-8<---------------cut here---------------start------------->8--- ;; Some generic functions (define get-file-like-object-path (file-like) "Because all file-like object get inserted literally by home services, we need a function, which returns a file, which contains a path to the file." (computed-file "tmp-file" #~#$file-like)) (define fl-append-strings (lst) "Accepts a list of strings and file-like object, reads the content of the file-like objects (to be consistent with behavior of home services configuration)." (define file-like->str (mb-file-like) (if (string? mb-file-like) mb-file-like #~(begin (use-modules (ice-9 rdelim)) (with-fluids ((%default-port-encoding "UTF-8")) (with-input-from-file #$mb-file-like read-string))))) (computed-file "tmp-file" #~(apply string-append '#$(map file-like->str lst)))) ;; A home service, declared in home-environment. (service home-zsh-service-type (home-zsh-configuration (zshrc (list (fl-append-strings (list "source " (get-file-like-object-path zsh-autosuggestions) "/share/zs../..ions.zsh")) ;; or "source \\" (get-file-like-object-path (file-append zsh-autosuggestions "/share/zs../..ions.zsh")))))) =2D-8<---------------cut here---------------end--------------->8--- Here we don't use gexps inside configuration and all file-like objects are "expanded" as their content instead of path in the store. It can work, but looks a little strange and hard to copmose. Perhaps, I miss something and doesn't see the whole picture, but for now expanding file-like objects to their content and throwing out gexps doesn't look appealing to me. BTW, I've skimmed through the paper "Code Staging in GNU Guix" and limitations section, still not sure what your concerns are, I'll try to re-read the paper and your message <87pmvqckws.fsf@gnu.org> one more time a few days later to better understand it. If you have a spare time, please make a simple code snippet, which demonstrates the problem you've mentioned in the message, which will hit the users of home services. It will help me to figure out possible shortcommings and better understand the problem. Ludovic, sorry for spending your time on that, but I really need to understand this thing better. Thank you in advance for hepling on that. Oleg, thank you for working on this patch series, much appreciate) =2D-=20 Best regards, Andrew Tropin --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEKEGaxlA4dEDH6S/6IgjSCVjB3rAFAmFdWyQACgkQIgjSCVjB 3rCm3xAAjsd63c+cTwumpE1H48QV4JifrjD25yU3p+Bal5h8KVW03eQBdz6eeSjD Bd1ukegCB+1Om0GEhd0W0i3mm6UF5xEj+neBAZLXyopqDIKd4HaQG/mR+3SNg99M nDP2VeTwSAZQb8WoLwl28eX6wTuAkXWBeGPA77icRcHmo9ItT6criYe3cgFjk0Ki TyhUKzHhmICJtziBLyglj6JiXapkJfK6DPk+7qCWCPxzXsbr8kL2fcOlgxKT+oAI PkR98VIO7xsrssOclKSAo1uYfskZQTBSMXt7+Xv2zfEdZRP1UWw98dPCN3lHCOJy OMK6VRLNdlN6pCl9DjxnF+a3RJaNgjBJLABZxHISdl/vm89OTWSs9IIYKza7NW/4 UbhwTg0zUwjn0W1H+DZqVG6GWlOHqcEnSoeUPJ8v/5mLM0CROCPeAEJB/3lnwIUn +SYHnLHXEMqz+caHCYDYC0fQ/kfxU7JEES+UzJ57Y+N0x0aANbvvjdQoL+Pv/GeD daaopcnZByhFEvsmOBy/D2tjgiUNUzLzir6rje6izx3NsWoKhP0Mj0/LRU3rHBZk BS6Stk8oykX8GsDlgUC+XnV+1oJmW2+Qc7Y7SjqzHza65HFH/ynyPsKnj6IjxarL 0lUG3CvKQVsJ+i+5Ix4fMzr/JQDKz/y10Gv9jois7QeFGdoOONs= =cA22 -----END PGP SIGNATURE----- --=-=-=--