help-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A Guix Home service to group together various email services


From: Fabio Natali
Subject: Re: A Guix Home service to group together various email services
Date: Tue, 02 Jul 2024 11:24:00 +0100

Hi Richard,

Thanks for taking the time and getting back to me. 🙏

On 2024-07-01, 18:12 -0400, Richard Sent <richard@freakingpenguin.com> wrote:
>> Anything that you think I'm doing wrong here? Could it be a limitation
>> with 'home-msmtp-service-type', which doesn't seem to indicate any
>> mechanism for extend/compose?
>
> Yes, I believe that's your problem. I don't see a reason why
> home-msmtp-service-type shouldn't support being extended with
> additional accounts. I think it's worth a bug or (even better) a
> patch.

After sending this to help-guix I had the chance to speak to a friend
who helped me understand Guix services a bit better. My friend mentioned
that I might consider simply aggregating services as lists, instead of
by extending them with a "superset" service.

Something along the lines of:

(define my/email-configuration-files-home-service
  (simple-service
   'email-configuration-files
   home-xdg-configuration-files-service-type
   `((...))))

(define my/email-mcron-home-service
  (simple-service
   'email-mcron
   home-mcron-service-type))

(define my/email-msmtp-home-service
  (service
   home-msmtp-service-type
   (home-msmtp-configuration (accounts my/msmtp-config))))

...

;; This is where the aggregation happens, via a list instead of by extending the
;; various services.
(define my/email-home-services
  (list
   my/email-configuration-files-home-service
   my/email-mcron-home-service
   my/email-msmtp-home-service
   ...))

...

(define my/home-environment
  (home-environment
   (services
    (concatenate
     my/email-home-services
     ...))))

I think using a list is indeed good enough for my current use case.

With regard to patching 'home-msmtp-service-type', I'm glad to look into
this but then I'm also worried that the same problem might present again
and again across various services.

I wonder whether the list-based approach (instead of the
service-extension approach) might be a better fit simply because of the
way services are designed at the moment?

> I'm surprised it's possible to extend a service that doesn't support
> extensions. In my opinion we should throw an explicit error instead of
> silently ignoring the extension. I reported this as a bug [1].

Yes, the fact that the reconfiguration went through with no error was
indeed a bit puzzling. Thanks for filing the bug report.

Best, cheers, Fabio.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]