GNU bug report logs - #36430
mcron would benefit from a better way to test jobs

Previous Next

Full log

View this message in rfc822 format

From: Ludovic Courtès <ludo <at> gnu.org>
To: Robert Vollmert <rob <at> vllmrt.net>
Cc: 36430 <at> debbugs.gnu.org
Subject: bug#36430: mcron would benefit from a better way to test jobs
Date: Mon, 08 Jul 2019 11:54:35 +0200

Hi,

Robert Vollmert <rob <at> vllmrt.net> skribis:

>> On 7. Jul 2019, at 16:24, Ludovic Courtès <ludo <at> gnu.org> wrote:
>> 
>> Hi Robert,
>> 
>> Robert Vollmert <rob <at> vllmrt.net> 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’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.