[bug#77041,15/16] services: mcron: Deprecate.

  * gnu/services/mcron.scm (mcron-service-type): Mark as deprecated.
* gnu/home/services/mcron.scm (home-mcron-service-type): Likewise.
* doc/guix.texi (Scheduled Job Execution): Document it.
(Mcron Home Service): Likewise.

Change-Id: I0329bf1ef5026d6b7d392a5807f0600ff28c3006
---
 doc/guix.texi               | 18 ++++++++++++++++++
 gnu/home/services/mcron.scm |  7 +++++--
 gnu/services/mcron.scm      |  7 +++++--
 3 files changed, 28 insertions(+), 4 deletions(-)
  

Hi,

Ludovic Courtès <ludo@gnu.org> writes:

> * gnu/services/mcron.scm (mcron-service-type): Mark as deprecated.
> * gnu/home/services/mcron.scm (home-mcron-service-type): Likewise.
> * doc/guix.texi (Scheduled Job Execution): Document it.
> (Mcron Home Service): Likewise.

While I think some documentation to mention that Shepherd timers can be
used instead of mcron for most cases, I do not see this as a reason to
deprecate nor remove the mcron service itself, just like we do not
remove system services when new, perhaps more modern alternatives get
added.
  

> While I think some documentation to mention that Shepherd timers can be
> used instead of mcron for most cases, I do not see this as a reason to
> deprecate nor remove the mcron service itself, just like we do not
> remove system services when new, perhaps more modern alternatives get
> added.

+1 on this.

Also, in the current state, while timers can be used in most places a
mcron service would be used normally, defining timer services is
somewhat more verbose. For example, defining an alarm service with mcron
is as simple as (1):

(simple-service 'home-alarm-service
                home-mcron-service-type
                (home-mcron-configuration
                 (jobs (list #~(job "0 6 * * *"
                                    "mpv --shuffle ~/media/music")))))

While doing it with shepherd would be something like (2):

(simple-service 'home-alarm-service
                home-shepherd-service-type
                (list (shepherd-service
                        (provision '(alarm))
                        (modules '((shepherd service timer)))
                        (start #~(make-timer-constructor
                                   (calendar-event #:hours '(6)
                                                   #:minutes '(0))
                                   (command '("mpv" "--shuffle" "~/media/music"))))
                        (stop #~(make-timer-destructor))
                        (actions (list shepherd-trigger-action)))))

I guess we could make it more succint by defining a
`home-shepherd-timer-service-type` (this name is already in use, but I
don't know a better one) for these timers services to extend, as I do
here:

https://codeberg.org/anemofilia/radix/src/branch/main/radix/services/shepherd.scm

With these definitions, the alarm service could be written, using
shepherd timers as (3):

(simple-service 'home-alarm-service
                home-shepherd-timer-service-type
                (list (shepherd-timer
                        (name 'alarm)
                        (event #~(calendar-event #:hours '(6)
                                                 #:minutes '(0)))
                        (action #~(command '("mpv" "--shuffle" "~/media/music"))))))

Which is only two lines longer than (1), while (2) is six lines longer.
I think the various services that provide shepherd timers would also
benefit from these definitions.

WDYT?

PS. I've sent this mail before but by mistake it was sent only to
Maxim, please disregard.
  

Luis Guilherme Coelho via Guix-patches via <guix-patches@gnu.org>
writes:

>> While I think some documentation to mention that Shepherd timers can be
>> used instead of mcron for most cases, I do not see this as a reason to
>> deprecate nor remove the mcron service itself, just like we do not
>> remove system services when new, perhaps more modern alternatives get
>> added.
>
> +1 on this.
>
> Also, in the current state, while timers can be used in most places a
> mcron service would be used normally, defining timer services is
> somewhat more verbose.
>
> [..]
>
> Which is only two lines longer than (1), while (2) is six lines longer.
> I think the various services that provide shepherd timers would also
> benefit from these definitions.

In my own configuration I went as far as:

--8<---------------cut here---------------start------------->8---
(services
  (cron-timer 'cron-btrfs-scrub-raid
              "0 4 1,15 * *"
              (script/btrfs-scrub "/raid"))
  ...)
--8<---------------cut here---------------end--------------->8---

And it even sends emails with the output, as crons should.

I am not saying Guix proper needs to go as far as I did, but I agree
that currently defining Shepherd timers is bit too verbose.

Tomas
  

Ludovic Courtès <ludo@gnu.org> writes:

> +@quotation Deprecation Warning
> +The @code{home-mcron-service-type} described below is superseded by
> +Shepherd timers and slated for removal after 2026-04-01.
> +@xref{Scheduled Job Execution}, for more information.
> +@end quotation
> +

Currently timers lack the ability to send email with the cron output,
something mcron can do.  Is that something you plan to address before
removing the mcron-service-type?

(Albeit saying "no" would probably be justified, the email sending was
broken for a long time and no one noticed, so I am unsure whether people
actually use it.)

Tomas
  

Hello,

"Luis Guilherme Coelho" <lgcoelho@disroot.org> skribis:

>> While I think some documentation to mention that Shepherd timers can be
>> used instead of mcron for most cases, I do not see this as a reason to
>> deprecate nor remove the mcron service itself, just like we do not
>> remove system services when new, perhaps more modern alternatives get
>> added.
>
> +1 on this.

To be honest, I also wondered about deprecation: I do value internal
consistency (I think services provided by Guix itself should all use the
same tool), but I think it’s OK if people want to keep using mcron.

So yes, some sort of “soft deprecation” as Maxim wrote sounds
reasonable to me.

Thoughts?

> Also, in the current state, while timers can be used in most places a
> mcron service would be used normally, defining timer services is
> somewhat more verbose. For example, defining an alarm service with mcron
> is as simple as (1):

[...]

> I guess we could make it more succint by defining a
> `home-shepherd-timer-service-type` (this name is already in use, but I
> don't know a better one) for these timers services to extend, as I do
> here:
>
> https://codeberg.org/anemofilia/radix/src/branch/main/radix/services/shepherd.scm

Yes, I was going to suggest something like this.

Could something similar to the ‘ganeti-timer’ procedure introduced in
this patch series?

  (define (ganeti-timer name schedule command)
    "Return a Shepherd timer providing NAME and running COMMAND, a list-valued
  gexp."
    (shepherd-service
     (provision (list name))
     (requirement '(user-processes))
     (modules '((shepherd service timer)))
     (start #~(make-timer-constructor
               #$(if (string? schedule)
                     #~(cron-string->calendar-event #$schedule)
                     schedule)
               (command '(#$@command))
               #:wait-for-termination? #t))
     (stop #~(make-timer-destructor))
     (documentation "Periodically run a Ganeti maintenance job.")
   (actions (list shepherd-trigger-action))))

Or maybe something higher-level that would extend
‘shepherd-root-service-type’?

Perhaps this should be done independently of this patch series though.

Thanks,
Ludo’.
  

Tomas Volf <~@wolfsden.cz> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> +@quotation Deprecation Warning
>> +The @code{home-mcron-service-type} described below is superseded by
>> +Shepherd timers and slated for removal after 2026-04-01.
>> +@xref{Scheduled Job Execution}, for more information.
>> +@end quotation
>> +
>
> Currently timers lack the ability to send email with the cron output,
> something mcron can do.  Is that something you plan to address

No.  :-)

I think it’s more convenient, more flexible, and safer to implement as a
higher-level mechanism, like you did in your personal services IIRC.

WDYT?

Ludo’.
  

Ludovic Courtès <ludo@gnu.org> writes:

> Tomas Volf <~@wolfsden.cz> skribis:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
>>
>>> +@quotation Deprecation Warning
>>> +The @code{home-mcron-service-type} described below is superseded by
>>> +Shepherd timers and slated for removal after 2026-04-01.
>>> +@xref{Scheduled Job Execution}, for more information.
>>> +@end quotation
>>> +
>>
>> Currently timers lack the ability to send email with the cron output,
>> something mcron can do.  Is that something you plan to address
>
> No.  :-)
>
> I think it’s more convenient, more flexible, and safer to implement as a
> higher-level mechanism, like you did in your personal services IIRC.
>
> WDYT?

Yeah, I think that is a reasonable approach. ^_^

Tomas