Hi Bruno, Bruno Victal <mi...@makinata.eu> writes:
> Hi, > > As the gnu/services and gnu/home/services grow, I think we should > consider divvying the services into stand-alone modules or > subdirectories. > > Consider the ⌜dovecot-service-type⌝ in gnu/services/mail.scm: as of > commit 'd22d2a05c389207f8cdcf824be7738b1499a987c' this service > definition is nearly 1600 lines long, with the remainder of the file > comprising of four other services with rudimentary support. > > It becomes troublesome working with such amalgamations as it makes it > hard to keep track of the used modules and bindings, especially when > define-configuration is used since the serializing procedures might be > used by various service definitions. Further complicating things is > 'define-maybe', whose use monopolizes the predicate and serializers for > a particular service definition. > > Now, I'm not saying that we should go and split everything into its own > module, I'm saying that we should be allowed to split some of them if > convenient (all subjective but I believe we can see that working with a > monolithic file in the kilolines where the interactions aren't obvious > is not fun, and that's without bringing in the hygienic issues > surrounding define-configuration and define-maybe). > > Some considerations (using dovecot-service-type as an example): > * Splitting this as gnu/services/mail/dovecot.scm. > We preserve the logical grouping of the services (with the addition > that, for extremely comprehensive definitions, these can be neatly > organized into subdirectories. (same structure seen with gnu/*.scm) > A drawback is that 'use-service-modules' might not work with this > although I wonder whether 'use-service-modules' & co. provide any > value if we are already doing '(use-modules (gnu) …)' to begin with. > They look redundant IMO. > > * Splitting this as gnu/services/dovecot.scm. > We keep it compatible with 'use-service-modules' at the cost of having > a multitude of files under gnu/services, without any logical grouping > (messy). That's a great initiative! I agree that multiple 'define-configuration' services per file can be a bit messy, having to use prefixes everywhere, making the definitions more verbose. I don't have a strong preference of the caterogization of services, but would perhaps prefer the first one (gnu/services/mail/dovecot.scm), which could then make it easy to offer some interface as gnu/services/mail.scm that'd re-export all that is needed (would that work, or reintroduce the same top-level clashes?). -- Thanks, Maxim
