[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Divvying up service definitions
From: |
Efraim Flashner |
Subject: |
Re: Divvying up service definitions |
Date: |
Thu, 9 Nov 2023 09:15:29 +0200 |
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