bug#36430: mcron would benefit from a better way to test jobs

[Ludovic Courtès]

Hi,

Robert Vollmert <address@hidden> skribis:

>> On 7. Jul 2019, at 16:24, Ludovic Courtès <address@hidden> wrote:
>> 
>> Hi Robert,
>> 
>> Robert Vollmert <address@hidden> skribis:
>> 
>>> Defined a mcron job in config.scm scheduled to run once a day,
>>> with a scheme expression. How do I test this?
>>> 
>>> herd schedule mcron lists the job as merely a “Lambda expression”.
>>> I learned how to give it a descriptive name, but still there’s
>>> no script linked that I can run by hand.
>> 
>> Commit 89fdd9ee0cc8817283449b33a8c1a2604c575c7e changes the rottlog job
>> in a simple way so we see an actual command rather than “Lambda
>> expression”.  I would recommend using this style to improve
>> transparency.
>
> I understand that passing an executable works better. But that also
> loses the feature of allowing to write a script in place advertised by
> the lambda variant.

In Guix, if you write:

  #~(job … #$(program-file "do-something" #~(begin …)))

instead of:

  #~(job … (lambda () …))

you’re still writing Scheme code, and the result is pretty much the
same.

Now, from a pure mcron viewpoint (if you were to use it outside Guix), I
agree that procedures are handled in a suboptimal way.  Mcron should
simply display the procedure object, which includes its source location
info.

Aternately it could display its source location info as obtained with
‘program-source’ if that helps readability:

--8<---------------cut here---------------start------------->8---
scheme@(guile-user)> ,use(system vm program)
scheme@(guile-user)> (program-source derivation (program-code derivation))
$6 = (2780 "guix/derivations.scm" 877 . 17)
--8<---------------cut here---------------end--------------->8---

> I find that kind of “feature that doesn’t actually work” to be quite
> painful.
>
> A way to get the best of both worlds (within guix) would be to use
> program-file / gexp, so maybe that’s what should be advertised in the
> guix manual?

Yes, definitely.

> At this stage, there’s just too many small hacking sessions required
> all over the place :). I’ll stick with filing bug reports for the
> clear pain points if that’s ok?

Sure, definitely!  It’s good to have all these pain points filed, and I
think many can be addressed quite easily, so that’ll help us improve
things gradually.

Thanks,
Ludo’.