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

[Andrew Tropin <andrew@trop.in>]

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

On 2021-10-08 09:56, Ludovic Courtès wrote:

> Hi Andrew,
>
> Andrew Tropin <andrew@trop.in> skribis:
>
>> 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 agree that nginx config is problematic:
>
>   https://issues.guix.gnu.org/37388
>
> But IMO that’s off-topic.  :-)
>

Even not taking into account that ngixn-configuration is not ideally
implemented, probably it still relevant:

1. Highlights the problem of current service configuration
implementation approach with records: we will need to mimic the whole
underlying configuration language with records, for some small languages
it's possible, but in general it's very thankless job, which also force
use to keep an eye on upstream configuration language, possible
extensions to it and keep our implementation in sync.  In addition to
that in most cases provided set of nested records requires destructuring
and custom serialization code.

Other system services also affected by this issue.

2. Usage of separate config-file fields with file-like object values is
problematic:

For nginx service it substitutes the whole file, for tor service it will
be inserted at the end of the file for service X it will be inserted at
the middle.


Using a slightly different approach, implemented in many home services
we get ultimate configuration flexibility, we don't need to handle
existing file as some special case, create a separate field for it and
wonder where it should be inserted, when provided.

I'll provide more details in a separate thread, but for now just take a
look at too implementations of sway services using both approaches:

https://notabug.org/jbranso/guix-config/src/master/sway-service.scm#L110
https://git.sr.ht/~abcdw/rde/tree/master/item/gnu/home-services/wm.scm#L33

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

>
> I’m happy to discuss specific service examples in mode details if you
> want.  Overall, I’m confident Home services don’t require any pattern
> that’s not already found in one of the many System services.  :-)
>
> HTH,
> Ludo’.

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.


-- 
Best regards,
Andrew Tropin

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