[bug#50967] file-like objects instead of gexps

[Andrew Tropin <andrew@trop.in>]

[-- Attachment #1: Type: text/plain, Size: 4399 bytes --]

On 2021-10-09 15:34, Ludovic Courtès wrote:

> Hi Andrew,
>
> Preamble: Guix Home is now committed and there are bug reports coming
> in.  To me, that means our discussion needs to be focused on addressing
> specific issues; we’re not going to redesign Guix services in this
> thread.
>
> Andrew Tropin <andrew@trop.in> skribis:
>
> [...]
>
>>> Then that’s fine: you can have special code that emits those “source”
>>> lines in .zshrc while still allowing users to provide their own
>>> file-like object for .zshrc lines they want to add.  Again, see how
>>> ‘torrc’ is generated in ‘tor-service-type’.
>>
>> From what I understand you want a separate bashrc-file,
>> bash-profile-file and bash-logout-file fields to be present, but where
>> the content of those files should be inserted?  At the beginning/end or
>> instead of the rest of configuration?
>>
>> We already can achieve the same result by providing gexp, which will
>> read the content of the file-like object, a very small helper for that
>> (slurp-file-gexp) makes it even easier to do.  Such approach is more
>> flexible and doesn't seem much harder.
>>
>> I remember that you had concerns about slurp-file-gexp, but still don't
>> understand what exactly you are concerned about.
>
> Let me restate my concerns:
>
>   1. Users are unlikely to fathom what this does, given the name.  It
>      will end up in user configurations, yet: “slurp”?  “gexp”?

Sounds like a naming conecrn, I brought "slurp" word from clojure lang,
but we can call it whatever sounds better for guile community
generate-read-whole-file-gexp or anything else.  Actually, we don't even
need to have this wrapper to be present, just allow people to do
#~(call-with-input-file file-like-object get-string-all)

>
>   2. ‘slurp-file-gexp’ returns code, as a gexp.  Depending on the place
>      where that gexp is inserted, it may or may not work.  Consider:
>
>        (define (foo x)
>          #~(frob '(#$x)))
>
>        (foo (slurp-file-gexp …))  ;d’oh!

Yep, users can make mistakes, but it's not a technical problem, also, I
see it quite unlikely to happen according to my experience supporting
Guix Home users.

>
>   3. Use of ‘slurp-file-gexp’ and gexps in configuration records is not
>      consistent with the rest of the service APIs (and I think we can
>      humbly recognize that those APIs have been doing the job for a
>      while already.)

It's not actually true, there are system services, which accept a list
of strings/gexps and state it in the documentation, some of them do it
in a less exlicit way, but still do, I found that trick looking at
system service and made it an explicit pattern for home services.  I
tried to extract and follow patterns from system services, but found
them quite inconsistent, so I took a few of them and wrote a few on my
own.

To name a few:
extra-options @ alsa-configuration
extra-config @ nix-configuration
extra-config @ xorg-configuration
extra-content @ nginx-configuration
extra-config @ httpd-config-file
contents @ httpd-virtualhost

To make guix services configurations consistent (at least new ones) I
think it would be cool to have a `Writing Service Configuration
Guideline` section.  I can share the design descisions I've made for
home services configurations and after a discussion it can end up in a
manual section giving a clean guideline, reducing subjective preferences
and increasing consistency.  If you are interested.

>
> Let’s just to the (call-with-input-file file get-string-all) dance in
> places where it’s needed rather than let users call ‘slurp-file-gexp’.
> This is roughly what the ‘tor-service-type’ example I gave does.
>
>> I'll write a few examples of service configurations and rationale behind
>> the design descisions for that next week, to make the discussion more
>> practically oriented.
>
> People are starting to use the tool and to report bugs.  So,
> unfortunately, we have to sort out interface issues quickly now.
>
> If some of the things being discussed turn out to be too complex to
> address under those time constraints, we can consider taking them out
> until we have a better idea on how to address them.
>
> How does that sound?
>
> Thanks,
> Ludo’.

-- 
Best regards,
Andrew Tropin

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]