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). -- Thanks, Bruno.
