On 2022-01-21 10:30, Maxime Devos wrote:

> Andrew Tropin schreef op do 20-01-2022 om 16:20 [+0300]:
>> [...]
>> 
>> 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")) 

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"))
                   
>
> * 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 ‘concatenated-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
>     <contents of the file "bar">
>
>     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 ‘copy this
>     and that file is the serialisation here and there’.
>
>     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:

--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/"))))))
--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-lines
and other escape hatches (We need to learn it everytime we write a new
service configuration).

but it could be:

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

-- 
Best regards,
Andrew Tropin