A Guix Home service to group together various email services

A Guix Home service to group together various email services

[Fabio Natali]

Hi. 👋

I'd like to define a Guix Home service that aggregates all my email
configuration together: mbsync, msmtp, Notmuch, and a couple of mcron
jobs.

So far, I've kept them as separate services but I thought it was nice
and cleaner having them grouped together.

I've been thinking of something along the lines of:

(define my/msmtp-config
  (list
   (msmtp-account
    (name "test")
    (configuration
     (msmtp-configuration
      (host "example.com")
      (user "user")
      ...)))
   ...))

(define my/home-email-service
  (service
   (service-type
    (name 'home-email)
    (extensions
     (list
      (service-extension home-mcron-service-type (const ...))
      (service-extension home-msmtp-service-type (const my/msmtp-config))
      (service-extension home-xdg-configuration-files-service-type (const ...))))
    (default-value #f)
    (description "Email service."))))

This mostly works:

- 'guix home reconfigure' runs smoothly, without warning or error.
- mbsync and Notmuch configuration files are correctly created.
- Guix Home cron jobs are also defined as expected.

However, msmtp is not configured correctly. The resulting file
'~/.config/msmtp/config' only contains the string 'defaults'.

I can successfully set up msmtp as a separate service like this:

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

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?

More generally, this way of aggregating services together in
'my/home-email-service', does it look like a good pattern or should I do
things any differently?

Thanks, cheers, Fabio.


-- 
Fabio Natali
https://fabionatali.com

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

[Richard Sent]

Fabio Natali <me@fabionatali.com> writes:

> 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.

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].

> More generally, this way of aggregating services together in
> 'my/home-email-service', does it look like a good pattern or should I do
> things any differently?

I find myself doing something similar in my config, although usually at
a smaller scale (not for any particular reason, just how it works out).
I think this is a good idea because your service is contained to one
logical unit—email—and there's likely no reason you'd want to only
include just one of the extensions in an environment.

[1]: https://issues.guix.gnu.org/71887

-- 
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.

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

[Fabio Natali]

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.