Hi, Robert Vollmert <r...@vllmrt.net> skribis:
> I’m currently writing some slightly repetitive mcron jobs > in my config.scm that use gexps / program-file. I’m wondering > whether there’s a better way to share code between these than > writing a separate scheme file and importing that via > with-imported-modules? > > That approach works, but it’s a bit painful because I can no > longer just “system reconfigure”, but need to deal with the > guile load path. Also I’d prefer to have config.scm self-contained. Modules in general are a good way to group related functionality, I think there’s no argument here. :-) So the question is really how one can avoid using multiple files, or at least passing ‘-L’ to ‘guix system reconfigure’. You could define your module directly in your config.scm: (define my-helpers #~(begin (define-module (helpers)) …)) Such a module can then be used along these lines: (with-imported-modules `(((helpers) => ,my-helpers)) #~(begin (use-modules (helpers)) …)) It may not work well with mcron jobs though, because there’s no good place (I think) where you could get that ‘use-modules’ form. Well, with an example we may be able to find more appropriate solutions. > It turns out to not be possible to use a config.scm-level function > via e.g. (#$funcname arg1 arg2) for what are probably good reasons. Remember that a gexp is a way to “stage” an expression for eventual execution—e.g., when your system boots, when your mcron job fires, etc. If ‘funcname’ exists as a function in memory when your config.scm program is evaluated, it cannot be magically transferred to those other stages. Instead, you would need to make the _source code_ of ‘funcname’ available to those other stages. HTH! Ludo’.