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

["Ludovic Courtès" <ludo@gnu.org>]

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”?

  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!

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

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