Hi Richard,
Thanks for taking the time and getting back to me. 🙏
On 2024-07-01, 18:12 -0400, Richard Sent <rich...@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.
