guix-devel
[Top][All Lists]
Advanced

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

Re: Return back original implementation for text-config serialization


From: Maxime Devos
Subject: Re: Return back original implementation for text-config serialization
Date: Sun, 09 Jan 2022 20:00:40 +0100
User-agent: Evolution 3.38.3-1

Andrew Tropin schreef op zo 09-01-2022 om 20:59 [+0300]:
> [...]
> I think we can just rely on something like that:
> --8<---------------cut here---------------start------------->8---
> #~(call-with-input-file #$(local-file "./files/bashrc")
>     (@ (ice-9 textual-ports) get-string-all))
> --8<---------------cut here---------------end--------------->8---
> 
> As I mentioned in reply to Liliana, from my experience it's a rare case,
> when we really need to slurp the content of the file, in most cases
> include/source and other similar consturctions can do the trick, so it
> maybe not necessary to have a helper for this case at all.
> 
> WDYT?
> 
> BTW, even after reading "Code Staging in GNU Guix" paper, I still not
> sure what the problem with slurp-file-gexp (except maybe name :) ).

Looking at the reasons at <https://issues.guix.gnu.org/52698>, the
issue seems mostly naming to me.  When I read 'slurp-file-gexp', what I
thought was happening, is that first the file-like object is lowered
and then the G-Exp of the builder is extracted from the derivation.

Maybe name it

(define (file-contents object)
  "Construct a G-expression that reads the file-like object OBJECT
and returns the contents as a string."
  ;; TODO: do we need to set the encoding to UTF-8 here?
  #~((@ (relevant guile module) call-with-input-file)
     #$object
     (@ (ice-9 textual-ports) get-string-all)))

That would avoid having to remember the (call-with-input-file ...)
trick.

Greetings,
Maxime.

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

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