Re: Return back original implementation for text-config serialization

[Andrew Tropin]

On 2022-01-18 15:26, Ludovic Courtès wrote:

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

Hi Ludovic,

It's not a justification for the changes it's a recap of the past events
to provide the context.  We were working on moving Guix Home and home
services from rde to guix, but in the middle of this process the change
to text-config type happend and now it's not possible to continue
upstreaming without rewriting the rest of home services in rde repo or
reverting back this change.

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

This is exactly what I want to achieve: To be able to collectively work
on one consistent implementation, but fee0bc, which slipped to the
master unreviewed, splitted home service configuration approach into two
competitive implementations, a few essential home services in guix repo
and bigger rest of non-essential stuck in rde.

I already mentioned at least two possible ways to handle this
situtation:
1. Rewrite the rest of rde home services.
2. Rollback this change.

I'm ok with both options, but #1 requires much more human hours to
complete and I still not sure if fee0bc was introduced for strong
reasons or was added almost accidentially.  So I try to find a
justification for this change.

From what I understood from Liliana's and Maxime's replies: I'm not the
only one finding the original implementation to be more intuitive and
consistent with the rest of Guix API.  Please, correct me if I'm wrong.

>> 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?
>

Just a 3 cases I observed in Guix Russia telegram chat.

>> 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?

I have very same question :)

It's what happens internally in current implementation, something like
that goes to home-files-service-type.

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

During the course of this year learned a lot of different service
configurations and approaches used in them and aware of this too.  We
can also mention some services, which has a special field, which accepts
a list of strings or string-valued G-exps, which will be added to the
end of the file like xorg-configuration or httpd-config-file.  Those
approaches have their own pros and cons and I already shared some
thoughts on this topic:

https://issues.guix.gnu.org/50967#65

Also, I already started work on 'Writing Service Configuration' section
in the manual, which is good platform for discussion and should help to
align our visions about service configurations and prevent some
unecessary discussion in the future:

https://issues.guix.gnu.org/52698

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

Users won't use this construction directly, it is just what hapenning
under the hood and looks a little too much excessive.

> 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?

IMO, changes to text-config in fee0bc really makes it harder to continue
the work on many Guix Home related tasks.

-- 
Best regards,
Andrew Tropin

signature.asc
Description: PGP signature