[Top][All Lists]

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

Re: Early feedback on Guix Home

From: Ludovic Courtès
Subject: Re: Early feedback on Guix Home
Date: Sat, 10 Jul 2021 16:18:11 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)


(Sorry for the late reply…)

Andrew Tropin <> skribis:

> Ludovic Courtès <> writes:


>>>> Possible action:
>>>>   1. Change config records to accept file-like objects instead of
>>>>      strings.  That way, users can choose to have snippets inlined (in a
>>>>      ‘plain-file’ object) or separate (via ‘local-file’).  See for
>>>>      example how ‘tor-configuration->torrc’ does it.
>>> Yeah, there is a ‘slurp-file-gexp’ procedure that let’s one read an
>>> extenal file, but using existing APIs like ‘local-file’ is probably a
>>> better idea.
>> Yes, it feels more natural.  Also, ‘slurp-file-gexp’ returns a gexp (a
>> code snippet), but as a user you don’t know where that snippet is going
>> to be inserted; it may not work in some contexts.
> Acually, the idea behind `slurp-file-gexp` is that you always know where
> it will be inserted, because it will be inside the specific section of
> the configuration.  Take a look at emacs home-service example:

What I mean is that, in a general sense, one cannot know whether the
gexp will be inserted in a place where it’s “valid”.  Consider the
following examples, where the gexp is meant to be inserted in lieu of

  #~(list '(#$PLACEHOLDER))  ;it’s quoted

  #~(let ((call-with-input-file (const #f)))

These are “hygiene” problems discussed in the “Code Staging in GNU Guix”

All this to say that, from an API viewpoint, I think it’s (1) more
robust, as I wrote, and (2) clearer to expect file-like objects in such
places.  It’s clearer because users can be expected to have an
understanding of what ‘local-file’ does, whereas ‘slurp-file-gexp’ is
more involved.

I hope this clarifies what I had in mind!


reply via email to

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