Hi, Xinglu Chen <pub...@yoctocell.xyz> writes:
> On Thu, Sep 23 2021, Ludovic Courtès wrote: > >> Hi, >> >> Xinglu Chen <pub...@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. > > (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)) > > 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. Interesting idea, although I'm a bit wary of adding yet more complexity to this already relatively complex macro. I'd favor the cleaner inheritance idea proposed by Maxime Devos. I wonder if some fields can even be masked or removed through inheritance or some other record transformation (haven't checked). > It’s probably going to be quite complicated, so it would be good to get > some feedback/thoughts on it. Cc Maxim since he has done some work with > (gnu services configuration). > > Also, it’s probably time to properly document (gnu services > configuration) in the manual. ;-) Agreed! Maxim