[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#36875] [PATCH] doc: Document the use of `program-file' for mcron jo
From: |
Ludovic Courtès |
Subject: |
[bug#36875] [PATCH] doc: Document the use of `program-file' for mcron jobs. |
Date: |
Mon, 26 Aug 2019 10:30:09 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) |
Hi Maxim,
Maxim Cournoyer <address@hidden> skribis:
> Ludovic Courtès <address@hidden> writes:
>
>> Hello!
>>
>> Maxim Cournoyer <address@hidden> skribis:
>>
>>> From 0fffed46b4899bf0485926399d3971a4b5e94408 Mon Sep 17 00:00:00 2001
>>> From: Maxim Cournoyer <address@hidden>
>>> Date: Thu, 1 Aug 2019 07:34:17 +0900
>>> Subject: [PATCH] doc: Document the use of `program-file' for mcron jobs.
>>>
>>> * doc/guix.texi (Scheduled Job Execution): Explain why using `program-file'
>>> for an mcron job can be necessary. Add an example.
>>
>> [...]
>>
>>> +For more complex jobs defined in Scheme, it is safer to pass the job as a
>>> +script to mcron; otherwise, macros defined or imported with
>>> @code{use-modules}
>>> +wouldn't expand correctly, as Guile requires macros to be strictly defined
>>> or
>>> +imported at the top level of a Guile module. This can be achieved using
>>> the
>>> +@code{program-file} procedure from the @code{(guix gexp)} module, as shown
>>> in
>>> +the example below.
>>
>> Macros are a very good example of the problem, but I wonder if it would
>> be clearer to simply write something like:
>>
>> For more complex jobs defined in Scheme where you need control over
>> the top level, for instance to introduce a @code{use-modules} form, you
>> can move your code to a separate program using the @code{program-file}
>> procedure of the @code{(guix gexp)} module (@pxref{G-Expressions}).
>> The example below illustrates that.
>
> I like your version, which feels to me more elegant. But, from my
> experimentation, using (use-modules) in a nested form is fine for
> anything else than syntax (macros).
That’s right, but I strongly recommend not relying on non-toplevel
‘use-modules’ because (1) it’s “ugly” because it introduces new bindings
at run time, and (2) it’s not guaranteed to work in the future—in fact,
the just-released Guile 2.9.4 introduces “declarative modules”, which is
probably a first step in the direction of less run-time trickery with
modules.
> This is now live as commit 1407ebeaa1. Thanks for feedback/review! :-)
Great, thank you!
Ludo’.