Re: Return back original implementation for text-config serialization

[Ludovic Courtès]

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’.