Re: Divvying up service definitions

2023-12-04 Thread Maxim Cournoyer
Hi Bruno, Bruno Victal writes: > Hi Efraim, > > On 2023-11-09 07:15, Efraim Flashner wrote: >> 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. > > They're not public but they override definitions within the same file >

Re: Divvying up service definitions

2023-11-28 Thread Bruno Victal
Hi Efraim, On 2023-11-09 07:15, Efraim Flashner wrote: > 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. They're not public but they override definitions within the same file if more than one (define-maybe foo) is present

Re: Divvying up service definitions

2023-11-16 Thread Ludovic Courtès
Hello! Maxim Cournoyer skribis: >> * 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

Re: Divvying up service definitions

2023-11-09 Thread Development of GNU Guix and the GNU System distribution.
Hi Bruno, On Thu, Oct 26 2023, Bruno Victal wrote: > Agreed, the crux of the discussion is splitting service-definitions into > their own modules. In the current naming scheme, the module (gnu services configuration) is an outlier: It does not ship "configuration services" but provides

Re: Divvying up service definitions

2023-11-08 Thread Efraim Flashner
On Tue, Nov 07, 2023 at 10:56:11AM -0500, Maxim Cournoyer wrote: > Hi Bruno, > > Bruno Victal 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

Re: Divvying up service definitions

2023-11-07 Thread Maxim Cournoyer
Hi Bruno, Bruno Victal 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

Re: Divvying up service definitions

2023-10-28 Thread Attila Lendvai
> I dont think there's any problem wrt categorization. For your Kerberos > example, either would be fine as they're not mutually exclusive. > (though I'd lean towards 'authentication' here) sure, but the crux of the issue here is how to improve code readability; i.e. would it make the humans

Re: Divvying up service definitions

2023-10-26 Thread Bruno Victal
Hi Felix, On 2023-10-24 18:54, Felix Lechner wrote: > The number of services we offer strikes me as sufficiently small for > your "unsorted" scheme to remain easy to navigate. I can see your point here if we're to do estimates and interpolation based on the growth of the services so far although

Re: Divvying up service definitions

2023-10-24 Thread Development of GNU Guix and the GNU System distribution.
Hi Bruno, On Tue, Oct 24 2023, Bruno Victal wrote: > Further complicating things is > 'define-maybe', whose use monopolizes the predicate and serializers for > a particular service definition. I've dealt with that in the past and support your effort. > * Splitting this as