[bug#36555] [PATCH 1/2] guix system: Add 'reconfigure' module.

[Ludovic Courtès]

Hello!

address@hidden (Jakob L. Kreuze) skribis:

> Ludovic Courtès <address@hidden> writes:

[...]

>> Can we remove ‘with-output-to-string’? I’d rather see what’s going on.
>> :-)
>>
>> If that’s too verbose, we can use ‘invoke/quiet’.
>
> I'm not too concerned with verbosity; rather, in the case for 'guix
> deploy', the script's output mixes with the REPL output and that causes
> 'remote-eval' to fail with a match error. I think it would be better to
> continue using 'with-output-to-string', but to preseve its return value
> so we can show it to the user from 'guix deploy' or 'guix system
> reconfigure'. Users of 'guix deploy' would also be able to see the
> script's output this way.

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.

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

>> It seems that this sort-of inlines parts of ‘shepherd-service-upgrade’
>> but without traversing the service dependency graph to determine the
>> compilete set of obsolete services, no? I feel that we should be
>> reusing ‘shepherd-service-upgrade’ or similar bits. (I realize this is
>> already in ‘master’ for ‘guix deploy’, but since this is going to be
>> shared with ‘guix system’, we’d rather be extra cautious.)
>
> Does 'live-service-requirement' not encompass the full service
> dependency graph? Regardless, I'll look into reusing
> 'shepherd-service-upgrade' as it's well-testsed.

‘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.

Thanks,
Ludo’.