On 2021-10-08 15:45, Xinglu Chen wrote:

> On Wed, Oct 06 2021, Andrew Tropin wrote:
>
>> 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---
>
> Wouldn’t something like the following work
>
> --8<---------------cut here---------------start------------->8---
> (service home-zsh-service-type
>          (home-zsh-configuration
>           (zshrc
>            (list (mixed-text-file
>                   "zshrc"
>                   "source "
>                   (file-append zsh-autosuggestions "/share/zsh/..."))
                     ^ place1
>                  (local-file "./some-zshrc")))))
                    ^ place2
> --8<---------------cut here---------------end--------------->8---
>
> and since ‘zshrc’ is already a list of file-like objects, we could
> implement ‘serialize-text-config’ using something like
> ‘fl-append-strings’, which would read the contents of the two files and
> append them.  That way users don’t have to deal with ‘fl-append-strings’
> or ‘slurp-file-gexp’.

Yep, it looks much better than what I was trying to prototype.

Still feels inconsistent that file-like object in place1 will be
evaluated to the path in the store, but in place2 to the content of the
file.

-- 
Best regards,
Andrew Tropin