On 2021-10-04 16:04, Ludovic Courtès wrote:

> Xinglu Chen <public@yoctocell.xyz> skribis:
>
>> On Sat, Oct 02 2021, Oleg Pykhalov wrote:
>>
>>> * gnu/home/services/configuration.scm (interpose): Include content of files.
>>> (string-or-gexp?): Rename to 'file-or-string-or-gexp?' and check for file-like
>>> object.
>>
>> I would call it ‘file-like-or-string-or-gexp?’, just ‘files’ doesn’t
>> really make it clear that it should be a “file-like object”.
>
> As a matter of API, I would make it monomorphic: accept a file-like
> object, period.  This is what’s 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:

--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/"))))))
--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.

>
> ‘plain-file’ and ‘scheme-file’ allow users to “convert” a string or a
> gexp into a file-like object.
>
> WDYT?
>
> Ludo’.
>
>
>

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:

--8<---------------cut here---------------start------------->8---
(service
 home-zsh-service-type
 (home-zsh-configuration
  (zshrc
   (list
    #~(string-append "source " #$zsh-autosuggestions "/share/zs../..ions.zsh")
    ;; or
    "source \\"
    (file-append zsh-autosuggestions "/share/zs../..ions.zsh")))))
--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:

--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"))))))
--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)


-- 
Best regards,
Andrew Tropin