unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Return back original implementation for text-config serialization
@ 2022-01-09  9:12 Andrew Tropin
  2022-01-09 11:19 ` Liliana Marie Prikler
                   ` (3 more replies)
  0 siblings, 4 replies; 12+ messages in thread
From: Andrew Tropin @ 2022-01-09  9:12 UTC (permalink / raw)
  To: guix-devel, Oleg Pykhalov, Ludovic Courtès
  Cc: Xinglu Chen, guix-maintainers

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

During the upstreaming process of Guix Home commit
fee0bced7fec2f9950957976a28f033edd4f877c slipped into master.  It
introduces a different serialization approach for text-config from what
was orginally used:
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services/configuration.scm?h=2c451db39aabc69bdbf186f412ee6e0b4e180ccb#n386

This new approach is inconisistent with the ideas used in the number of
other home services (not only the ones using text-config):
https://git.sr.ht/~abcdw/rde/tree/47f6c65c82a4f6761fa1ff5b9405b363cfda6482/item/gnu/home-services

So I had to fork it back to avoid an inconsistency and renamed
text-config to gexp-text-config to avoid a confusion with upstreamed
version.
https://git.sr.ht/~abcdw/rde/tree/47f6c65c82a4f6761fa1ff5b9405b363cfda6482/item/gnu/home-services-utils.scm#L355

Having two serialization approaches stops me from upstreaming the rest
of home services from rde to Guix and also makes a split to rde home
services and guix home services, which I would like to avoid.

We need to decide, which approach should be used or we will end up with
two competitive incompatible implementations and unecessary split of
effort and lose of human force and time.

I wanted to solve this question as a part of
https://issues.guix.gnu.org/52698, but seems it doesn't get enough
attention (probably cause of the volume of information in the patch).

I'll provide a few technical details, which supports the original
appoarch.

Before fee0bc serialization for text-config worked this way:
--8<---------------cut here---------------start------------->8---
`("string here"
  ,#~"string valued gexp"
  "source \"
  ,(local-file "blabla.sh"))
--8<---------------cut here---------------end--------------->8---

would yeld something like:

--8<---------------cut here---------------start------------->8---
string here
string valued gexp
source \
/gnu/store/00fl96dj2aak4i1vqvdqzlhbmmskc7fx-blabla.sh
--8<---------------cut here---------------end--------------->8---


There is another less generalized example, which demonstrates how
serialization of sway configuration works right now.

--8<---------------cut here---------------start------------->8---
`((include ,(local-file "./sway/config"))
  (bindsym $mod+Ctrl+Shift+a exec
           ,(file-append emacs "/bin/emacsclient") -c --eval "'(eshell)'")
  (bindsym $mod+Ctrl+Shift+o "[class=\"IceCat\"]" kill)
  (input * ((xkb_layout us,ru)
            (xkb_variant dvorak,))))
--8<---------------cut here---------------end--------------->8---

would yield something like:

--8<---------------cut here---------------start------------->8---
include /gnu/store/408jwvh6wxxn1j85lj95fniih05gx5xj-config
bindsym $mod+Ctrl+Shift+a exec /gnu/store/...-emacsclient -c --eval '(eshell)'
bindsym $mod+Ctrl+Shift+o [class="IceCat"] kill
input * {
    xkb_layout us,ru
    xkb_variant dvorak,
}
--8<---------------cut here---------------end--------------->8---

The new text-config serialization implementation (after fee0bc commit)
doesn't support gexps and tries to insert the literal content of the
file in place where file-like object was used, which

1. Confuses the users.
People reporting that it's hard to implement something like

source \
/gnu/store/00fl96dj2aak4i1vqvdqzlhbmmskc7fx-blabla.sh

with the new approach (using file-like objects), and they switch to the
original implementation of home services for shells (the ones currently
living in rde repo), which allows to use gexps.

2. Looks strange implementation-wise.

If we want to insert the file path to file-like object for new-style
text-config internally we do something like

(mixed-text-file ...
 "source \" "\n"
 #~(read-everything-from-file
    #$(computed-file "unecessary-file-name"
       #~#$(local-file "blabla.sh"))))

when originally it was
(mixed-text-file
 "source \" "\n"
 (local-file "blabla.sh"))

3. Inconsistent with other home services.

I do not insist that one approach is superior to the other and there are
of course some pros and cons for both of them, but personally I find the
old one to be more user-friendly, simpler and cleaner.  Also, having the
new implementation stops me from upstreaming all other home services,
because almost all of them allows to use gexps inside configuration
field and resolves file-like object to the path in the store instead of
literal content.

Please, express arguments, opinions and rationales and let's decide:
Keep the new approach or return back to the original one.

-- 
Best regards,
Andrew Tropin

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Return back original implementation for text-config serialization
  2022-01-09  9:12 Return back original implementation for text-config serialization Andrew Tropin
@ 2022-01-09 11:19 ` Liliana Marie Prikler
  2022-01-09 17:48   ` Andrew Tropin
  2022-01-09 12:17 ` Maxime Devos
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 12+ messages in thread
From: Liliana Marie Prikler @ 2022-01-09 11:19 UTC (permalink / raw)
  To: Andrew Tropin, guix-devel, Oleg Pykhalov, Ludovic Courtès
  Cc: Xinglu Chen, guix-maintainers

Hi Andrew,

Am Sonntag, dem 09.01.2022 um 12:12 +0300 schrieb Andrew Tropin:
> Before fee0bc serialization for text-config worked this way:
> --8<---------------cut here---------------start------------->8---
> `("string here"
>   ,#~"string valued gexp"
>   "source \"
>   ,(local-file "blabla.sh"))
> --8<---------------cut here---------------end--------------->8---
> 
> would yield something like:
> 
> --8<---------------cut here---------------start------------->8---
> string here
> string valued gexp
> source \
> /gnu/store/00fl96dj2aak4i1vqvdqzlhbmmskc7fx-blabla.sh
> --8<---------------cut here---------------end--------------->8---
> 
> [...]
> 
> The new text-config serialization implementation (after fee0bc
> commit) doesn't support gexps and tries to insert the literal content
> of the file in place where file-like object was used[.]
I agree that the old one looks nicer in this context, but wasn't the
new one introduced to solve the issue of (slurp-file-gexp) in the
importer?  Meaning whichever way we go, we need something that allows
us to insert literal file contents of another file at more or less G-
exp compile time.

Perhaps that issue could be solved, if instead the importer just reads
the file contents and declares it as a variable as in
(define %bashrc "
;; Original contents of bashrc
")
(define bashrc (plain-file %bashrc)).

WDYT?

> If we want to insert the file path to file-like object for new-style
> text-config internally we do something like
> 
> (mixed-text-file ...
>  "source \" "\n"
>  #~(read-everything-from-file
>     #$(computed-file "unecessary-file-name"
>        #~#$(local-file "blabla.sh"))))
> 
> when originally it was
> (mixed-text-file
>  "source \" "\n"
>  (local-file "blabla.sh"))
Is unnecessary-file-name ever created in this instance?  I think we
have something similar in other locations as well, where G-expressions
are merged -- public keys for substitutes spring to mind.  Perhaps all
it'd need to make use of new-style text configs is a better way of
quoting such things, e.g. a procedure which takes a file-like object
and produces a plain file with its name.

For the record, the use of (read-everything-from-file) in your example
-- a procedure which I'm unable to find in my local Guix checkout --
makes it somewhat difficult to come up with concrete solutions here, so
pardon me for being abstract.


Cheers


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Return back original implementation for text-config serialization
  2022-01-09  9:12 Return back original implementation for text-config serialization Andrew Tropin
  2022-01-09 11:19 ` Liliana Marie Prikler
@ 2022-01-09 12:17 ` Maxime Devos
  2022-01-09 12:19 ` Maxime Devos
  2022-01-18 14:26 ` Ludovic Courtès
  3 siblings, 0 replies; 12+ messages in thread
From: Maxime Devos @ 2022-01-09 12:17 UTC (permalink / raw)
  To: Andrew Tropin, guix-devel, Oleg Pykhalov, Ludovic Courtès
  Cc: Xinglu Chen, guix-maintainers

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

Andrew Tropin schreef op zo 09-01-2022 om 12:12 [+0300]:
> [...] There is another less generalized example, which demonstrates
> how
> serialization of sway configuration works right now.
> 
> --8<---------------cut here---------------start------------->8---
> `((include ,(local-file "./sway/config"))
>   (bindsym $mod+Ctrl+Shift+a exec
>            ,(file-append emacs "/bin/emacsclient") -c --eval
> "'(eshell)'")
>   (bindsym $mod+Ctrl+Shift+o "[class=\"IceCat\"]" kill)
>   (input * ((xkb_layout us,ru)
>             (xkb_variant dvorak,))))
> --8<---------------cut here---------------end--------------->8---
> 
> would yield something like:
> 
> --8<---------------cut here---------------start------------->8---
> include /gnu/store/408jwvh6wxxn1j85lj95fniih05gx5xj-config
> bindsym $mod+Ctrl+Shift+a exec /gnu/store/...-emacsclient -c --eval
> '(eshell)'
> bindsym $mod+Ctrl+Shift+o [class="IceCat"] kill
> input * {
>     xkb_layout us,ru
>     xkb_variant dvorak,
> }
> --8<---------------cut here---------------end--------------->8---
> 
> The new text-config serialization implementation (after fee0bc
> commit)
> doesn't support gexps and tries to insert the literal content of the
> file in place where file-like object was used, which
> 
> 1. Confuses the users. [...]
> 2. Looks strange implementation-wise. [...]
> (mixed-text-file ...
> "source \" "\n"
> #~(read-everything-from-file
>    #$(computed-file "unecessary-file-name"
>       #~#$(local-file "blabla.sh"))))
> when originally it was
> (mixed-text-file
>  "source \" "\n"
>  (local-file "blabla.sh"))

Can we have (mixed-text-file "source \" "\n" (local-file "blabla.sh"))
and the sway configuration you quoted?  That syntax seems reasonable
and easy to use to me.  But without reintroducing slurp-file-gexp.

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Return back original implementation for text-config serialization
  2022-01-09  9:12 Return back original implementation for text-config serialization Andrew Tropin
  2022-01-09 11:19 ` Liliana Marie Prikler
  2022-01-09 12:17 ` Maxime Devos
@ 2022-01-09 12:19 ` Maxime Devos
  2022-01-09 17:59   ` Andrew Tropin
  2022-01-18 14:26 ` Ludovic Courtès
  3 siblings, 1 reply; 12+ messages in thread
From: Maxime Devos @ 2022-01-09 12:19 UTC (permalink / raw)
  To: Andrew Tropin, guix-devel, Oleg Pykhalov, Ludovic Courtès
  Cc: Xinglu Chen, guix-maintainers

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

Andrew Tropin schreef op zo 09-01-2022 om 12:12 [+0300]:
> [...] There is another less generalized example, which demonstrates
> how
> serialization of sway configuration works right now.
> 
> --8<---------------cut here---------------start------------->8---
> `((include ,(local-file "./sway/config"))
>   (bindsym $mod+Ctrl+Shift+a exec
>            ,(file-append emacs "/bin/emacsclient") -c --eval
> "'(eshell)'")
>   (bindsym $mod+Ctrl+Shift+o "[class=\"IceCat\"]" kill)
>   (input * ((xkb_layout us,ru)
>             (xkb_variant dvorak,))))
> --8<---------------cut here---------------end--------------->8---
> 
> would yield something like:
> 
> --8<---------------cut here---------------start------------->8---
> include /gnu/store/408jwvh6wxxn1j85lj95fniih05gx5xj-config
> bindsym $mod+Ctrl+Shift+a exec /gnu/store/...-emacsclient -c --eval
> '(eshell)'
> bindsym $mod+Ctrl+Shift+o [class="IceCat"] kill
> input * {
>     xkb_layout us,ru
>     xkb_variant dvorak,
> }
> --8<---------------cut here---------------end--------------->8---
> 
> The new text-config serialization implementation (after fee0bc
> commit)
> doesn't support gexps and tries to insert the literal content of the
> file in place where file-like object was used, which
> 
> 1. Confuses the users. [...]
> 2. Looks strange implementation-wise. [...]
> (mixed-text-file ...
> "source \" "\n"
> #~(read-everything-from-file
>    #$(computed-file "unecessary-file-name"
>       #~#$(local-file "blabla.sh"))))
> when originally it was
> (mixed-text-file
>  "source \" "\n"
>  (local-file "blabla.sh"))

Can we have (mixed-text-file "source \" "\n" (local-file "blabla.sh"))
and the sway configuration you quoted?  That syntax seems reasonable
and easy to use to me.  But without reintroducing slurp-file-gexp.

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Return back original implementation for text-config serialization
  2022-01-09 11:19 ` Liliana Marie Prikler
@ 2022-01-09 17:48   ` Andrew Tropin
  2022-01-09 19:44     ` Liliana Marie Prikler
  0 siblings, 1 reply; 12+ messages in thread
From: Andrew Tropin @ 2022-01-09 17:48 UTC (permalink / raw)
  To: Liliana Marie Prikler, guix-devel, Oleg Pykhalov, Ludovic Courtès
  Cc: Xinglu Chen, guix-maintainers

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

On 2022-01-09 12:19, Liliana Marie Prikler wrote:

> Hi Andrew,
>
> Am Sonntag, dem 09.01.2022 um 12:12 +0300 schrieb Andrew Tropin:
>> Before fee0bc serialization for text-config worked this way:
>> --8<---------------cut here---------------start------------->8---
>> `("string here"
>>   ,#~"string valued gexp"
>>   "source \"
>>   ,(local-file "blabla.sh"))
>> --8<---------------cut here---------------end--------------->8---
>> 
>> would yield something like:
>> 
>> --8<---------------cut here---------------start------------->8---
>> string here
>> string valued gexp
>> source \
>> /gnu/store/00fl96dj2aak4i1vqvdqzlhbmmskc7fx-blabla.sh
>> --8<---------------cut here---------------end--------------->8---
>> 
>> [...]
>> 
>> The new text-config serialization implementation (after fee0bc
>> commit) doesn't support gexps and tries to insert the literal content
>> of the file in place where file-like object was used[.]
> I agree that the old one looks nicer in this context, but wasn't the
> new one introduced to solve the issue of (slurp-file-gexp) in the
> importer?  Meaning whichever way we go, we need something that allows
> us to insert literal file contents of another file at more or less G-
> exp compile time.
>

From my experience the usage of slurp-file-gexp is somewhat really rare,
so I didn't upstream it originally, keeping in mind that it is possible
to use the gexp mentioned below directly and that later we can add
slurp-file-gexp or alternative if necessary.  Just missed that importer
already uses it.

We could just do something like that instead of slurp-file-gexp:
--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---

Or just take the implementation
https://git.sr.ht/~abcdw/rde/tree/47f6c65c82a4f6761fa1ff5b9405b363cfda6482/gnu/home-services-utils.scm#L90
and rename it to read-file-content-gexp or somewhat more apropriate and
use it.

> 
> Perhaps that issue could be solved, if instead the importer just reads
> the file contents and declares it as a variable as in (define %bashrc
> " ;; Original contents of bashrc ") (define bashrc (plain-file
> %bashrc)).
>
> WDYT?
>

Another possible solution, but I would prefer to stick with the direct
usage of gexp with the code for reading a file, because importer is
intended for creation of an example configuration and user will need to
continue the work on it and copying the content of bashrc and other
configs to scheme files, escaping string can be a little tedious.

>> If we want to insert the file path to file-like object for new-style
>> text-config internally we do something like
>> 
>> (mixed-text-file ...
>>  "source \" "\n"
>>  #~(read-everything-from-file
>>     #$(computed-file "unecessary-file-name"
>>        #~#$(local-file "blabla.sh"))))
>> 
>> when originally it was
>> (mixed-text-file
>>  "source \" "\n"
>>  (local-file "blabla.sh"))
> Is unnecessary-file-name ever created in this instance?  I think we
> have something similar in other locations as well, where G-expressions
> are merged -- public keys for substitutes spring to mind.  Perhaps all
> it'd need to make use of new-style text configs is a better way of
> quoting such things, e.g. a procedure which takes a file-like object
> and produces a plain file with its name.
>
> For the record, the use of (read-everything-from-file) in your example
> -- a procedure which I'm unable to find in my local Guix checkout --
> makes it somewhat difficult to come up with concrete solutions here, so
> pardon me for being abstract.

read-everything-from-file is just a shorthand for

--8<---------------cut here---------------start------------->8---
#~(begin
    (use-modules (ice-9 rdelim))
    (with-fluids ((%default-port-encoding "UTF-8"))
      (with-input-from-file #$COMPUTED_FILE_CALL_HERE read-string)))
--8<---------------cut here---------------end--------------->8---

a gexp used in
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services/configuration.scm?h=2c451db39aabc69bdbf186f412ee6e0b4e180ccb#n386

The example was already verbose, so I decided to simplify it a little
bit.

Actually, it's very similar to what slurp-file-gexp does, but it's moved
inside serializer and hidden from user.  Why not to give it to the user
and eleminate two more layers of wrapping in gexps and file-likes.

To demonstrate the idea of those additional layers, I'll "rephrase" the
previous example in slightly different form.

Originally it was:
--8<---------------cut here---------------start------------->8---
(mixed-text-file
 ...
 ;; evaluated to path to the store
 file-like
 ;; evaluated to the string value ; 1
 gexp ; can be the result of slurp-file-gexp function if we
      ; need the file content
 ;; evaluated to itself
 "string")
--8<---------------cut here---------------end--------------->8---

It became:
--8<---------------cut here---------------start------------->8---
(mixed-text-file
 ...
 ;; evaluated to path to the store ; 2
 (read-everything-from-file (mixed-text-file "intermediate-name" file-like))
 ;; evaluated to the string value ; 3
 (read-everything-from-file (computed-file "intermediate-name" gexp))
 ;; evaluated to itself
 "string")
--8<---------------cut here---------------end--------------->8---

New style is not that bad, especially having some helper functions
(get-file-path file-like) and (get-value-of-gexp gexp) for 2 and 3, but
why?  Especially, if we can have only one slurp-file-gexp like helper
for 1, which is rarely used and maybe not even really needed.

-- 
Best regards,
Andrew Tropin

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Return back original implementation for text-config serialization
  2022-01-09 12:19 ` Maxime Devos
@ 2022-01-09 17:59   ` Andrew Tropin
  2022-01-09 19:00     ` Maxime Devos
  0 siblings, 1 reply; 12+ messages in thread
From: Andrew Tropin @ 2022-01-09 17:59 UTC (permalink / raw)
  To: Maxime Devos, guix-devel, Oleg Pykhalov, Ludovic Courtès
  Cc: Xinglu Chen, guix-maintainers

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

On 2022-01-09 13:19, Maxime Devos wrote:

> Andrew Tropin schreef op zo 09-01-2022 om 12:12 [+0300]:
>> [...] There is another less generalized example, which demonstrates
>> how
>> serialization of sway configuration works right now.
>> 
>> --8<---------------cut here---------------start------------->8---
>> `((include ,(local-file "./sway/config"))
>>   (bindsym $mod+Ctrl+Shift+a exec
>>            ,(file-append emacs "/bin/emacsclient") -c --eval
>> "'(eshell)'")
>>   (bindsym $mod+Ctrl+Shift+o "[class=\"IceCat\"]" kill)
>>   (input * ((xkb_layout us,ru)
>>             (xkb_variant dvorak,))))
>> --8<---------------cut here---------------end--------------->8---
>> 
>> would yield something like:
>> 
>> --8<---------------cut here---------------start------------->8---
>> include /gnu/store/408jwvh6wxxn1j85lj95fniih05gx5xj-config
>> bindsym $mod+Ctrl+Shift+a exec /gnu/store/...-emacsclient -c --eval
>> '(eshell)'
>> bindsym $mod+Ctrl+Shift+o [class="IceCat"] kill
>> input * {
>>     xkb_layout us,ru
>>     xkb_variant dvorak,
>> }
>> --8<---------------cut here---------------end--------------->8---
>> 
>> The new text-config serialization implementation (after fee0bc
>> commit)
>> doesn't support gexps and tries to insert the literal content of the
>> file in place where file-like object was used, which
>> 
>> 1. Confuses the users. [...]
>> 2. Looks strange implementation-wise. [...]
>> (mixed-text-file ...
>> "source \" "\n"
>> #~(read-everything-from-file
>>    #$(computed-file "unecessary-file-name"
>>       #~#$(local-file "blabla.sh"))))
>> when originally it was
>> (mixed-text-file
>>  "source \" "\n"
>>  (local-file "blabla.sh"))
>
> Can we have (mixed-text-file "source \" "\n" (local-file "blabla.sh"))
> and the sway configuration you quoted?  That syntax seems reasonable
> and easy to use to me.  But without reintroducing slurp-file-gexp.
>
> Greetings,
> Maxime.

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 :) ).

-- 
Best regards,
Andrew Tropin

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Return back original implementation for text-config serialization
  2022-01-09 17:59   ` Andrew Tropin
@ 2022-01-09 19:00     ` Maxime Devos
  0 siblings, 0 replies; 12+ messages in thread
From: Maxime Devos @ 2022-01-09 19:00 UTC (permalink / raw)
  To: Andrew Tropin, guix-devel, Oleg Pykhalov, Ludovic Courtès
  Cc: Xinglu Chen, guix-maintainers

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

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 #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Return back original implementation for text-config serialization
  2022-01-09 17:48   ` Andrew Tropin
@ 2022-01-09 19:44     ` Liliana Marie Prikler
  2022-01-10  9:49       ` Andrew Tropin
  0 siblings, 1 reply; 12+ messages in thread
From: Liliana Marie Prikler @ 2022-01-09 19:44 UTC (permalink / raw)
  To: Andrew Tropin, guix-devel, Oleg Pykhalov, Ludovic Courtès
  Cc: Xinglu Chen, guix-maintainers

Hi,

Am Sonntag, dem 09.01.2022 um 20:48 +0300 schrieb Andrew Tropin:
> On 2022-01-09 12:19, Liliana Marie Prikler wrote:
> 
> > Hi Andrew,
> > 
> > Am Sonntag, dem 09.01.2022 um 12:12 +0300 schrieb Andrew Tropin:
> > 
> > > Before fee0bc serialization for text-config worked this way:
> > > --8<---------------cut here---------------start------------->8---
> > > `("string here"
> > >   ,#~"string valued gexp"
> > >   "source \"
> > >   ,(local-file "blabla.sh"))
> > > --8<---------------cut here---------------end--------------->8---
> > > 
> > > would yield something like:
> > > 
> > > --8<---------------cut here---------------start------------->8---
> > > string here
> > > string valued gexp
> > > source \
> > > /gnu/store/00fl96dj2aak4i1vqvdqzlhbmmskc7fx-blabla.sh
> > > --8<---------------cut here---------------end--------------->8---
> > > 
> > > [...]
> > > 
> > > The new text-config serialization implementation (after fee0bc
> > > commit) doesn't support gexps and tries to insert the literal
> > > content
> > > of the file in place where file-like object was used[.]
> > I agree that the old one looks nicer in this context, but wasn't
> > the new one introduced to solve the issue of (slurp-file-gexp) in
> > the importer?  Meaning whichever way we go, we need something that
> > allows us to insert literal file contents of another file at more
> > or less G- exp compile time.
> > 
> 
> From my experience the usage of slurp-file-gexp is somewhat really
> rare, so I didn't upstream it originally, keeping in mind that it is
> possible to use the gexp mentioned below directly and that later we
> can add slurp-file-gexp or alternative if necessary.  Just missed
> that importer already uses it.
> 
> We could just do something like that instead of slurp-file-gexp:
> --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---
> 
> Or just take the implementation
> https://git.sr.ht/~abcdw/rde/tree/47f6c65c82a4f6761fa1ff5b9405b363cfda6482/gnu/home-services-utils.scm#L90
> and rename it to read-file-content-gexp or somewhat more apropriate
> and use it.
Using ill-defined slurp-patterns at all just adds ways of shooting
yourself in the foot.  You're turning Guix into an ouroboros that reads
itself inside-out.  Better restrict such patterns to where they cause
the least harm and make their effects very explicit.

> > Perhaps that issue could be solved, if instead the importer just
> > reads the file contents and declares it as a variable as in (define
> > %bashrc " ;; Original contents of bashrc ") (define bashrc (plain-
> > file %bashrc)).
> > 
> > WDYT?
> 
> Another possible solution, but I would prefer to stick with the
> direct usage of gexp with the code for reading a file, because
> importer is intended for creation of an example configuration and
> user will need to continue the work on it and copying the content of
> bashrc and other configs to scheme files, escaping string can be a
> little tedious.
There is certainly a tradeoff here, but I think explicitly showing
(plain-file CONTENT) is the right approach here.  Users are going to
figure out mixed-text-file exists soon enough.  As for proper string
escaping, that's not really an excuse imo -- pretty-print exists and
you can use it. 

> read-everything-from-file is just a shorthand for
> 
> --8<---------------cut here---------------start------------->8---
> #~(begin
>     (use-modules (ice-9 rdelim))
>     (with-fluids ((%default-port-encoding "UTF-8"))
>       (with-input-from-file #$COMPUTED_FILE_CALL_HERE read-string)))
> --8<---------------cut here---------------end--------------->8---
> 
> a gexp used in
> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services/configuration.scm?h=2c451db39aabc69bdbf186f412ee6e0b4e180ccb#n386
> 
> The example was already verbose, so I decided to simplify it a little
> bit.
> 
> Actually, it's very similar to what slurp-file-gexp does, but it's
> moved inside serializer and hidden from user.  Why not to give it to
> the user and eleminate two more layers of wrapping in gexps and file-
> likes.
That's like saying "memory management already exists, but it's hidden
from the user, why not let them play around with malloc?"  In
programming languages that aren't C/C++, abstractions ought to make it
harder to shoot yourself in the foot.  You (in my POV correctly)
pointed out that our current handling of text configs makes it very
easy to shoot yourself in the foot and is therefore badly abstracted. 
The point I'm making is that we shouldn't swap out one bad abstraction
for another, but pave the road towards good abstractions, e.g. G-
expressions in the way the rest of Guix typically uses them.

Now one thing I had not considered back in my previous mail was that we
want to be able to compose bashrc together from multiple sources, so
having the field be just one file-like object probably won't cut it. 
However, we can let it be a list of file like objects (with a field
sanitizer transparently turning a single file-like object into a list
either silently or loudly).  And within those file-like objects, we can
use the usual semantics.

I'm not sure how the current implementation of Guix Home handles
composition, but I believe the root of the issue probably stems from
there in some capacity.  Might want to check what our requirements are.


Cheers


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Return back original implementation for text-config serialization
  2022-01-09 19:44     ` Liliana Marie Prikler
@ 2022-01-10  9:49       ` Andrew Tropin
  2022-01-10 20:12         ` Liliana Marie Prikler
  0 siblings, 1 reply; 12+ messages in thread
From: Andrew Tropin @ 2022-01-10  9:49 UTC (permalink / raw)
  To: Liliana Marie Prikler, guix-devel, Oleg Pykhalov, Ludovic Courtès
  Cc: Xinglu Chen, guix-maintainers

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

On 2022-01-09 20:44, Liliana Marie Prikler wrote:

> Hi,
>
> Am Sonntag, dem 09.01.2022 um 20:48 +0300 schrieb Andrew Tropin:
>> On 2022-01-09 12:19, Liliana Marie Prikler wrote:
>> 
>> > Hi Andrew,
>> > 
>> > Am Sonntag, dem 09.01.2022 um 12:12 +0300 schrieb Andrew Tropin:
>> > 
>> > > Before fee0bc serialization for text-config worked this way:
>> > > --8<---------------cut here---------------start------------->8---
>> > > `("string here"
>> > >   ,#~"string valued gexp"
>> > >   "source \"
>> > >   ,(local-file "blabla.sh"))
>> > > --8<---------------cut here---------------end--------------->8---
>> > > 
>> > > would yield something like:
>> > > 
>> > > --8<---------------cut here---------------start------------->8---
>> > > string here
>> > > string valued gexp
>> > > source \
>> > > /gnu/store/00fl96dj2aak4i1vqvdqzlhbmmskc7fx-blabla.sh
>> > > --8<---------------cut here---------------end--------------->8---
>> > > 
>> > > [...]
>> > > 
>> > > The new text-config serialization implementation (after fee0bc
>> > > commit) doesn't support gexps and tries to insert the literal
>> > > content
>> > > of the file in place where file-like object was used[.]
>> > I agree that the old one looks nicer in this context, but wasn't
>> > the new one introduced to solve the issue of (slurp-file-gexp) in
>> > the importer?  Meaning whichever way we go, we need something that
>> > allows us to insert literal file contents of another file at more
>> > or less G- exp compile time.
>> > 
>> 
>> From my experience the usage of slurp-file-gexp is somewhat really
>> rare, so I didn't upstream it originally, keeping in mind that it is
>> possible to use the gexp mentioned below directly and that later we
>> can add slurp-file-gexp or alternative if necessary.  Just missed
>> that importer already uses it.
>> 
>> We could just do something like that instead of slurp-file-gexp:
>> --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---
>> 
>> Or just take the implementation
>> https://git.sr.ht/~abcdw/rde/tree/47f6c65c82a4f6761fa1ff5b9405b363cfda6482/gnu/home-services-utils.scm#L90
>> and rename it to read-file-content-gexp or somewhat more apropriate
>> and use it.
> Using ill-defined slurp-patterns at all just adds ways of shooting
> yourself in the foot.  You're turning Guix into an ouroboros that reads
> itself inside-out.  Better restrict such patterns to where they cause
> the least harm and make their effects very explicit.

Not sure what you mean.

>> > Perhaps that issue could be solved, if instead the importer just
>> > reads the file contents and declares it as a variable as in (define
>> > %bashrc " ;; Original contents of bashrc ") (define bashrc (plain-
>> > file %bashrc)).
>> > 
>> > WDYT?
>> 
>> Another possible solution, but I would prefer to stick with the
>> direct usage of gexp with the code for reading a file, because
>> importer is intended for creation of an example configuration and
>> user will need to continue the work on it and copying the content of
>> bashrc and other configs to scheme files, escaping string can be a
>> little tedious.
> There is certainly a tradeoff here, but I think explicitly showing
> (plain-file CONTENT) is the right approach here.  Users are going to
> figure out mixed-text-file exists soon enough.  As for proper string
> escaping, that's not really an excuse imo -- pretty-print exists and
> you can use it. 

Yep, of course it possible, but I mean that the whole point of escape
hatch is to make it possible to reuse existing files directly whithout
any manipulation on them and importer should demonstrate how to do it.
If importer internally do some manipulation (escaping) with the content
of the file and places the result in the string in scheme file, user
won't be able to replicate such process easily for other services, which
not covered by the importer. If I understood correctly what you meant in
the first message.

>> read-everything-from-file is just a shorthand for
>> 
>> --8<---------------cut here---------------start------------->8---
>> #~(begin
>>     (use-modules (ice-9 rdelim))
>>     (with-fluids ((%default-port-encoding "UTF-8"))
>>       (with-input-from-file #$COMPUTED_FILE_CALL_HERE read-string)))
>> --8<---------------cut here---------------end--------------->8---
>> 
>> a gexp used in
>> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services/configuration.scm?h=2c451db39aabc69bdbf186f412ee6e0b4e180ccb#n386
>> 
>> The example was already verbose, so I decided to simplify it a little
>> bit.
>> 
>> Actually, it's very similar to what slurp-file-gexp does, but it's
>> moved inside serializer and hidden from user.  Why not to give it to
>> the user and eleminate two more layers of wrapping in gexps and file-
>> likes.
> That's like saying "memory management already exists, but it's hidden
> from the user, why not let them play around with malloc?"  In
> programming languages that aren't C/C++, abstractions ought to make it
> harder to shoot yourself in the foot.  You (in my POV correctly)
> pointed out that our current handling of text configs makes it very
> easy to shoot yourself in the foot and is therefore badly abstracted.

Mostly my point was that it's more intuitive to expect that file-like
objects get serialized to the file path in the store and string-valued
gexps to the strings (as they does when we use them in mixed-text-file
for example), but new approach doesn't allow to use gexps directly and
serializes file-likes to it's content and requires much more hassle.

In both cases it's possible to use both gexps and file-likes, but in the
second one we have a few more levels of nestiness of gexps inside
file-likes inside gexps, which seems unecessary.

> The point I'm making is that we shouldn't swap out one bad abstraction
> for another, but pave the road towards good abstractions, e.g. G-
> expressions in the way the rest of Guix typically uses them.

Actually, for me, the original implementation looks consistent with how
the rest of Guix treats G-expressions (uses already known abstraction)
and only new one intoduces a new abstraction.

We can treat slurp-file-gexp as an abstraction here, but actually
1. this is more a tiny helper function, than an abstraction.

On 2022-01-09 20:00, Maxime Devos wrote:
> That would avoid having to remember the (call-with-input-file ...)
> trick.

2. this function is not really necessary.

>
> Now one thing I had not considered back in my previous mail was that we
> want to be able to compose bashrc together from multiple sources, so
> having the field be just one file-like object probably won't cut it. 
> However, we can let it be a list of file like objects (with a field
> sanitizer transparently turning a single file-like object into a list
> either silently or loudly).  And within those file-like objects, we can
> use the usual semantics.

I considered this option, but the problem is that we can't control the
place where the content will be inserted.  Let's assume it will go at
the end of the bashrc (we can demonstrate the similar if it will be
added to the beginning).

(home-bash-configuration
 (bashrc
  (list "call_function_from_lib_A()"))
 (bashrc-content
  (list (local-file "lib_A.sh"))))

which will make a call before lib_A loaded.  Also, it's already possible
to achieve the same with gexps/file-like in both new and old text-config
implementations.

In reality, it's rarely needed to insert the content directly, in most
cases it better to source/include/whatever file from the store.

With old implementation it will look like:

(home-bash-configuration
 (bashrc
  (list
   "source \\"
   (local-file "lib_A.sh")
   ;; Or an alternative way to do the same with gexp
   ;; #~(format #f "source ~a" #$(local-file "lib_A.sh"))
   "call_function_from_lib_A()")))

With new implementation:

(home-bash-configuration
 (bashrc
  (list
   "source \\"
   (mixed-text-file
    "unecessary-name"
    (local-file "lib_A.sh"))
   ;; Or an alternative way to do the same with gexp
   ;; (computed-file
   ;;  "unecessary-name"
   ;;  #~(format #f "source ~a" #$(local-file "lib_A.sh")))
   "call_function_from_lib_A()")))

which not that bad, but still looks more verbose, less intuitive and
consistent with the rest of the Guix (at least in my perception of it).

* All the code examples are in a pseudocode and maybe don't work and
  used mostly to demonstarte the idea, provide a feeling of how final
  configurations look.

>
> I'm not sure how the current implementation of Guix Home handles
> composition, but I believe the root of the issue probably stems from
> there in some capacity.  Might want to check what our requirements are.


It's offtopic, but when you will have time please take a look at
https://issues.guix.gnu.org/52388.

-- 
Best regards,
Andrew Tropin

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Return back original implementation for text-config serialization
  2022-01-10  9:49       ` Andrew Tropin
@ 2022-01-10 20:12         ` Liliana Marie Prikler
  2022-01-12 15:05           ` Andrew Tropin
  0 siblings, 1 reply; 12+ messages in thread
From: Liliana Marie Prikler @ 2022-01-10 20:12 UTC (permalink / raw)
  To: Andrew Tropin, guix-devel, Oleg Pykhalov, Ludovic Courtès
  Cc: Xinglu Chen, guix-maintainers

Am Montag, dem 10.01.2022 um 12:49 +0300 schrieb Andrew Tropin:
> [T]he whole point of escape hatch is to make it possible to reuse
> existing files directly without any manipulation on them and importer
> should demonstrate how to do it.
That'd make more sense if the importer copied bashrc to some well-known
location (e.g. ~/.config/guix/data/.bashrc) and then used that rather
than the file it wishes to replace.  IIRC that was one suggested
behaviour of Guix Home in the past, but it didn't get approval because
users wouldn't typically ask for that copying to happen.  If you make
it so that plain-file is used normally, but add a switch to express
things in terms of local-file instead, that'd work.  

OTOH, I do think local-file is already well-documented on its own, so
perhaps it'd only take a cookbook entry to show it in combination with
Guix Home and an explanation as to why Guix Home doesn't do that
normally while explaining all the caveats.

> If importer internally do some manipulation (escaping) with the
> content of the file and places the result in the string in scheme
> file, user won't be able to replicate such process easily for other
> services, which not covered by the importer. If I understood
> correctly what you meant in the first message.
Yes, the user would have to manually quote every new line of code
they're adding, but they're free to use all other file-like objects,
including local-file.  Having (bashrc (local-file ".bashrc")), whether
implemented on top of slurp-file-gexp or not, is inherently dangerous,
though.

> > The point I'm making is that we shouldn't swap out one bad
> > abstraction for another, but pave the road towards good
> > abstractions, e.g. G-expressions in the way the rest of Guix
> > typically uses them.
> 
> Actually, for me, the original implementation looks consistent with
> how the rest of Guix treats G-expressions (uses already known
> abstraction) and only new one intoduces a new abstraction.
That's the point.  The old style works just like you'd expect it to, it
becomes a problem when you try to feed it stuff like slurp-file-gexp to
work around some limitations in a way I'm not convinced makes sense.

> [I]t's already possible to achieve the same [-- merging multiple
> bashrc snippets into a single file --] with gexps/file-like in both
> new and old text-config implementations.
I find the lack of services in your example concerning, but I'll take
your word for it.  In that case, using a gexp for bashrc in the typical
sense is probably the best idea, but we still need to do something with
the reliance on slurp-file-gexp.

Cheers

> 
PS:
> It's offtopic, but when you will have time please take a look at
> https://issues.guix.gnu.org/52388.
Hahaha, it's been a month, hasn't it?  There's some aesthetic
unpleasanties, so I'm not sure if I'll upstream it with slight
stylistic changes or give you some harsher feedback, but I'll try to
decide this weekend.



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Return back original implementation for text-config serialization
  2022-01-10 20:12         ` Liliana Marie Prikler
@ 2022-01-12 15:05           ` Andrew Tropin
  0 siblings, 0 replies; 12+ messages in thread
From: Andrew Tropin @ 2022-01-12 15:05 UTC (permalink / raw)
  To: Liliana Marie Prikler, guix-devel, Oleg Pykhalov, Ludovic Courtès
  Cc: Xinglu Chen, guix-maintainers

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


On 2022-01-10 21:12, Liliana Marie Prikler wrote:

> Am Montag, dem 10.01.2022 um 12:49 +0300 schrieb Andrew Tropin:
>> [T]he whole point of escape hatch is to make it possible to reuse
>> existing files directly without any manipulation on them and importer
>> should demonstrate how to do it.
> That'd make more sense if the importer copied bashrc to some well-known
> location (e.g. ~/.config/guix/data/.bashrc) and then used that rather
> than the file it wishes to replace.  IIRC that was one suggested
> behaviour of Guix Home in the past, but it didn't get approval because
> users wouldn't typically ask for that copying to happen.  If you make
> it so that plain-file is used normally, but add a switch to express
> things in terms of local-file instead, that'd work.  
>
> OTOH, I do think local-file is already well-documented on its own, so
> perhaps it'd only take a cookbook entry to show it in combination with
> Guix Home and an explanation as to why Guix Home doesn't do that
> normally while explaining all the caveats.

It seems that current implementation of importer copy files to the
directory provided as command line argument and after that generates a
config file, which refers those files with local-file.

Overall, I think that the importer is not really well-defined both in
terms of purpose and implementation and maybe it will be better to hold
it until it polished.

>> If importer internally do some manipulation (escaping) with the
>> content of the file and places the result in the string in scheme
>> file, user won't be able to replicate such process easily for other
>> services, which not covered by the importer. If I understood
>> correctly what you meant in the first message.
> Yes, the user would have to manually quote every new line of code
> they're adding, but they're free to use all other file-like objects,
> including local-file.  Having (bashrc (local-file ".bashrc")), whether
> implemented on top of slurp-file-gexp or not, is inherently dangerous,
> though.
>

From this

>> > The point I'm making is that we shouldn't swap out one bad
>> > abstraction for another, but pave the road towards good
>> > abstractions, e.g. G-expressions in the way the rest of Guix
>> > typically uses them.
>> 
>> Actually, for me, the original implementation looks consistent with
>> how the rest of Guix treats G-expressions (uses already known
>> abstraction) and only new one intoduces a new abstraction.
> That's the point.  The old style works just like you'd expect it to, it
> becomes a problem when you try to feed it stuff like slurp-file-gexp to
> work around some limitations in a way I'm not convinced makes sense.
>

and this, it looks like you are concerned with local-file, which can
lead to the non-reproducible code, when for example the local-file
refers something outside of the git repo and on another machine the same
config will lead to an error?  And slurp-file-gexp additionally hides it
from the user by wrapping local-file.  Correct me if I'm wrong.

>> [I]t's already possible to achieve the same [-- merging multiple
>> bashrc snippets into a single file --] with gexps/file-like in both
>> new and old text-config implementations.
> I find the lack of services in your example concerning, but I'll take
> your word for it.  In that case, using a gexp for bashrc in the typical
> sense is probably the best idea, but we still need to do something with
> the reliance on slurp-file-gexp.
>
> Cheers
>
>> 
> PS:
>> It's offtopic, but when you will have time please take a look at
>> https://issues.guix.gnu.org/52388.
> Hahaha, it's been a month, hasn't it?  There's some aesthetic
> unpleasanties, so I'm not sure if I'll upstream it with slight
> stylistic changes or give you some harsher feedback, but I'll try to
> decide this weekend.
>

Yep :)  Thank you, will be waiting for it!)

-- 
Best regards,
Andrew Tropin

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Return back original implementation for text-config serialization
  2022-01-09  9:12 Return back original implementation for text-config serialization Andrew Tropin
                   ` (2 preceding siblings ...)
  2022-01-09 12:19 ` Maxime Devos
@ 2022-01-18 14:26 ` Ludovic Courtès
  3 siblings, 0 replies; 12+ messages in thread
From: Ludovic Courtès @ 2022-01-18 14:26 UTC (permalink / raw)
  To: Andrew Tropin; +Cc: guix-devel, Xinglu Chen, guix-maintainers

Hi,

Andrew Tropin <andrew@trop.in> skribis:

> During the upstreaming process of Guix Home commit
> fee0bced7fec2f9950957976a28f033edd4f877c slipped into master.  It
> introduces a different serialization approach for text-config from what
> was orginally used:
> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services/configuration.scm?h=2c451db39aabc69bdbf186f412ee6e0b4e180ccb#n386
>
> This new approach is inconisistent with the ideas used in the number of
> other home services (not only the ones using text-config):
> https://git.sr.ht/~abcdw/rde/tree/47f6c65c82a4f6761fa1ff5b9405b363cfda6482/item/gnu/home-services
>
> So I had to fork it back to avoid an inconsistency and renamed
> text-config to gexp-text-config to avoid a confusion with upstreamed
> version.
> https://git.sr.ht/~abcdw/rde/tree/47f6c65c82a4f6761fa1ff5b9405b363cfda6482/item/gnu/home-services-utils.scm#L355
>
> Having two serialization approaches stops me from upstreaming the rest
> of home services from rde to Guix and also makes a split to rde home
> services and guix home services, which I would like to avoid.

I’d like to clarify how I think we should work.  Guix development
happens here, on Guix channels, using the project’s peer review
processes.

What rde does certainly is inspirational, and that’s what got us Home in
the first place; in my view, we may sometimes choose to take ideas from
rde in Guix and Guix Home, but rde development alone cannot be used to
justify changes.

> We need to decide, which approach should be used or we will end up with
> two competitive incompatible implementations and unecessary split of
> effort and lose of human force and time.

Making Guix Home part of Guix was and still is a commitment, in
particular the commitment that we’d all be working on one
implementation, that there are no “competitive incompatible
implementations”.  It’s a choice we made, not a phenomenon we’re
passively observing.

[...]

> The new text-config serialization implementation (after fee0bc commit)
> doesn't support gexps and tries to insert the literal content of the
> file in place where file-like object was used, which
>
> 1. Confuses the users.
> People reporting that it's hard to implement something like
>
> source \
> /gnu/store/00fl96dj2aak4i1vqvdqzlhbmmskc7fx-blabla.sh
>
> with the new approach (using file-like objects), and they switch to the
> original implementation of home services for shells (the ones currently
> living in rde repo), which allows to use gexps.

Are there Guix Home issues reporting this?

> 2. Looks strange implementation-wise.
>
> If we want to insert the file path to file-like object for new-style
> text-config internally we do something like
>
> (mixed-text-file ...
>  "source \" "\n"
>  #~(read-everything-from-file
>     #$(computed-file "unecessary-file-name"
>        #~#$(local-file "blabla.sh"))))

When would one write such a thing?

A couple of examples from Guix System: <cgit-configuration> has an
‘include’ field take accepts file-like objects, <tor-configuration> has
a ‘config-file’ field.

Guix System users probably never have to use complicated constructs like
the one above.  Why would it be different for Home services?


Are there any new arguments since the already lengthy discussions that
led to fee0bced7fec2f9950957976a28f033edd4f877c?  Is it really what’s
leading to Guix Home being stale, or is there something else?

Thanks,
Ludo’.


^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2022-01-18 15:44 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-09  9:12 Return back original implementation for text-config serialization Andrew Tropin
2022-01-09 11:19 ` Liliana Marie Prikler
2022-01-09 17:48   ` Andrew Tropin
2022-01-09 19:44     ` Liliana Marie Prikler
2022-01-10  9:49       ` Andrew Tropin
2022-01-10 20:12         ` Liliana Marie Prikler
2022-01-12 15:05           ` Andrew Tropin
2022-01-09 12:17 ` Maxime Devos
2022-01-09 12:19 ` Maxime Devos
2022-01-09 17:59   ` Andrew Tropin
2022-01-09 19:00     ` Maxime Devos
2022-01-18 14:26 ` Ludovic Courtès

Code repositories for project(s) associated with this inbox:

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).