Re: Code sharing between system and home services (was Re: On the naming of System and Home services modules.)

[Xinglu Chen <public@yoctocell.xyz>]

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

On Fri, Sep 24 2021, Maxime Devos wrote:

> Xinglu Chen schreef op vr 24-09-2021 om 15:35 [+0200]:
>> On Thu, Sep 23 2021, Ludovic Courtès wrote:
>> 
>> > Hi,
>> > 
>> > Xinglu Chen <public@yoctocell.xyz> skribis:
>> > 
>> > > Some services might be useful to have in both Guix System and Guix Home;
>> > > for instance, Guix System currently has a service for configuring
>> > > Syncthing, and I think it makes sense to also have one for Guix Home,
>> > > this would mean that people not using Guix System (me :-)) could also
>> > > have Guix manage Syncthing.  With the current approach, we would have to
>> > > copy and paste quite a bit of code, and if the Syncthing service for
>> > > Guix System changes, then the one for Guix Home might have to change as
>> > > well.
>> > 
>> > Silly question, but why do we need to have two different configuration
>> > record types in the first place?
>> 
>> The problem is that the configuration records for system and home
>> service don’t necessarily have the same fields.  The Syncthing service
>> for Guix System has a ‘user’ and a ‘group’ field, which is not really of
>> any use in Guix Home, as the only user would be the user invoking ‘guix
>> home’.
>> 
>> > Sharing configuration between Home and System sounds important to me: it
>> > means users can easily move services from one to the other, which is
>> > pretty big deal.  It also means we’d have much less code to maintain.
>> 
>> Agreed, that’s what I would like to see as well.
>> 
>> > Would that be feasible?  (Apologies if this has already been
>> > discussed!)
>> 
>> Since it might not make sense to have the same records fields for a
>> system service and home service, I proposed (in the mail you replied to)
>> a ‘define-configuration’ form that would generate a configuration record
>> for a system service and optionally one for a home service, without
>> having to maintain two records separately.
>> 
>> --8<---------------cut here---------------start------------->8---
>> (define-configuration syncthing-configuration
>>   (package
>>    (package syncthing)
>>    "Syncthing package to use.")
>>   (arguments
>>    (list-of-strings ’())
>>    "Command line arguments to pass to the Syncthing package.")
>>   (log-flags
>>    (integer 0)
>>    "Sum of logging flags.")
>>   (user
>>    (maybe-string 'disabled)
>>    "The user as which the Syncthing service is to be run."
>>    (home-service? #f))  ; not for Guix Home
>>   (group
>>    (string "users")
>>    "The group as which the Syncthing service is to be run."
>>    (home-service? #f))  ; likewise ^^
>>   (home
>>    (maybe-string 'disabled)
>>    "Common configuration and data directory.")
>>   (home-service? #t))
>> --8<---------------cut here---------------end--------------->8---
>> 
>> It would generate <syncthing-configuration> and
>> <home-syncthing-configuration>.  The only difference being that
>> <home-syncthing-configuration> doesn’t have a ‘user’ and a ‘group’
>> field.
>
> The 'parent' mechanism (rnrs records syntactic) 'parent' could be used
> here (after adapting it to define-configuration), to define three record types:
>
> The record type with all fields common to the home configuration and system configuration
> (<common-syncthing-configuration> + common-syncthing-configuration?)
> and the record types for the home and system configuration
> (<syncthing-configuration> + syncthing-configuration? and <home-syncthing-configuration>
> + home-syncthing-configuration?).
>
> Using this mechanism, all syncthing-configuration? and home-syncthing-configuration?
> are common-syncthing-configuration?.

I didn’t know about the parent mechanism; that could be an approach to
take.  But since ‘define-configuration’ is based on (guix records),
would it make sense to adapt (guix records) to (rnrs records syntactic)
instead of SRFI-9 records?


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