guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Xinglu Chen
Subject: [bug#50967] file-like objects instead of gexps
Date: Fri, 08 Oct 2021 15:45:51 +0200

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/..."))
                 (local-file "./some-zshrc")))))
--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’.

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]