Subject: [bug#43494] [PATCH 2/4] services: guix: Add guix-build-coordinator-service-type.

From: Ludovic Courtès <[email-masked]>
Date: Fri, 25 Sep 2020 11:42:17 +0200

Hi!

Christopher Baines <[email-masked]> skribis:

> Ludovic Courtès <[email-masked]> writes:

[...]

>>> +  (program-file
>>> +   "start-guix-build-coordinator"
>>> +   (with-extensions (cons guix-build-coordinator-package
>>> +                          ;; This is a poorly constructed Guile load path,
>>> +                          ;; since it contains things that aren't Guile
>>> +                          ;; libraries, but it means that the Guile libraries
>>> +                          ;; needed for the Guix Build Coordinator don't need
>>> +                          ;; to be individually specified here.
>>> +                          (map second (package-inputs
>>> +                                       guix-build-coordinator-package)))
>>
>> Perhaps there should eventually be a ‘guix-build-coordinator’ command in
>> the package itself?
>
> There actually is, one thing I've had in mind for a while now though is
> to use a scheme script constructed by the Guix service to run the
> coordinator.
>
> For guix.cbaines.net, I'm using the script, but with the hooks passed in
> on the command line, the command is rather long, and it means that
> backtraces don't work well with the hooks.

You mean because the hooks are interpreted, and so all you see in the
backtrace is a bunch of ‘eval’ calls?

> I'm unsure how well this has worked out, I didn't anticipate the issues
> with the Guile load path, and because of the formatting stripping, both
> the code and backtraces will be unreadable anyway... but it is useful in
> allowing G-expressions to be used as part of the configuration.

OK.

Thanks,
Ludo’.