Ludovic Courtès <ludo@gnu.org> writes:

> Oh, I see. So in a way the problem is that ‘remote-eval’ doesn’t do
> anything sensible with the output and error ports of that remote
> evaluation.
>
> Ultimately we should probably fix (guix inferior) and (guix remote) so
> that stdout and stderr are properly transmitted.

Thinking about it now, that could make error reporting for 'guix deploy'
less complicated. We'd be able to output the remote's stdout/stderr to
the host's stdout/stderr and be done with it.

> In the meantime, what about this patch?
>
> diff --git a/guix/remote.scm b/guix/remote.scm
> index e503c76167..8ada5c0957 100644
> --- a/guix/remote.scm
> +++ b/guix/remote.scm
> @@ -76,8 +76,14 @@ result to the current output port using the (guix repl) protocol."
>    (with-imported-modules (source-module-closure '((guix repl)))
>      #~(begin
>          (use-modules (guix repl))
> -        (send-repl-response '(primitive-load #$program)
> +
> +        ;; We use CURRENT-OUTPUT-PORT for REPL messages, so redirect PROGRAM's
> +        ;; output to CURRENT-ERROR-PORT so that it does not interfere.
> +        (send-repl-response '(with-output-to-port (current-error-port)
> +                               (lambda ()
> +                                 (primitive-load #$program)))
>                              (current-output-port))
> +
>          (force-output))))
>  
>  (define* (remote-eval exp session

LGTM, thanks!

> ‘live-service-requirement’ gives you the graph of the currently loaded
> services, but you also need the target service graph to determine what
> to upgrade; that seems to be missing currently.

Oh, good catch. Reusing 'shepherd-service-upgrade' is certainly the way
to go, then.

Regards,
Jakob