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 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 and >> . The only difference being that >> 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?) > and the record types for the home and system configuration > ( + syncthing-configuration? and > + 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?