Re: Tracking and inspecting how Guix changes over time

[Christopher Baines <mail@cbaines.net>]

[-- Attachment #1: Type: text/plain, Size: 1745 bytes --]


Ricardo Wurmus <rekado@elephly.net> writes:

> Christopher Baines <mail@cbaines.net> writes:
>
>>> For an automated system like this, it’s a bit different, so using a
>>> container makes a lot of sense.  I’d suggest having an option directly
>>> in (guix inferior) to allow users to choose whether to run an inferior
>>> in separate name spaces.  WDYT?
>>
>> That sounds great, I'm not quite sure how to make it happen though...
>>
>> So inferior-pipe in (guix inferior) uses open-pipe*. The root of the
>> Linux container code in Guix looks to be run-container (gnu build
>> linux-container).
>
> You can use “call-with-container”, which runs a thunk inside a container.

I did see that, but I'm unsure how it would be applicable. What would
the thunk do?

In trying to isolate the inferior Guix, the natural separation point
that I've been considering is the point between the host Guix, and the
inferior Guix that communicate over a pipe.

Since the isolation relates to processes, it would be great if the repl
process could run in a "container", while the process that started the
repl remains outside of the container.

As far as I see it, you could start the repl from within the thunk
passed to "call-with-container", but then you've got three processes in
play. The repl is running in a container, and it's connected to by the
process that launched the repl after being cloned from the third initial
process that called call-with-container. At this point, doing stuff with
the information from the inferior Guix is a little difficult as it's all
happening in the container. When then thunk ends, the only information
that gets back to the remaining process is the exit status from waitpid.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 962 bytes --]