Re: Divvying up service definitions

[Efraim Flashner]

On Tue, Nov 07, 2023 at 10:56:11AM -0500, Maxim Cournoyer wrote:
> Hi Bruno,
> 
> Bruno Victal <mirai@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?).

I assume the define-maybe's aren't public, so I'd guess that shouldn't
cause a problem as long as they aren't exported.  There's some services,
like ntpd and openntpd, which reuse the service user/group between them,
I think with those being intentional about making sure there aren't
clashes, or making sure they line up, would also be a good choice.

Or moving the define-maybes to the top of the file and reusing them
between services. Is that a possibility?

-- 
Efraim Flashner   <efraim@flashner.co.il>   רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

signature.asc
Description: PGP signature