mbox

[bug#36668,0/1] Add 'eval/container'

Message ID 20190715142126.14612-1-ludo@gnu.org
Headers show

Message

Ludovic Courtès July 15, 2019, 2:21 p.m. UTC 
Hello Guix!

This adds ‘eval/container’, which can be used to implement things that
are almost derivation (pure computational processes), but not quite:
processes that produce side effects, that need to access the daemon,
or that need to talk over the network.

It doesn’t have any users currently.  Guix-Jupyter-Kernel will probably
use it (to spawn proxied kernels in isolated environments), and I think
Ricardo had a use case for it in GWL too.

What do people think?

I wonder if we should target ‘run-in-container’ instead of
‘call-with-container’, or maybe both.  It’s also a bit troubling
that ‘eval/container’ returns an exit status instead of the evaluation
result, but I think it has to be this way, more or less.

Ludo’.

Ludovic Courtès (1):
  linux-container: Add 'eval/container'.

 gnu/system/linux-container.scm | 49 ++++++++++++++++++++++++++++++++-
 tests/containers.scm           | 50 ++++++++++++++++++++++++++++++++++
 2 files changed, 98 insertions(+), 1 deletion(-)

Comments

Thompson, David July 15, 2019, 3:22 p.m. UTC | #1 
Hi Ludo,

On Mon, Jul 15, 2019 at 10:22 AM Ludovic Courtès <ludo@gnu.org> wrote:
>
> Hello Guix!
>
> This adds ‘eval/container’, which can be used to implement things that
> are almost derivation (pure computational processes), but not quite:
> processes that produce side effects, that need to access the daemon,
> or that need to talk over the network.
>
> It doesn’t have any users currently.  Guix-Jupyter-Kernel will probably
> use it (to spawn proxied kernels in isolated environments), and I think
> Ricardo had a use case for it in GWL too.
>
> What do people think?

This is great.  Love to see 'call-with-container' used for new things.

> I wonder if we should target ‘run-in-container’ instead of
> ‘call-with-container’, or maybe both.

I am behind the times. What is special about 'run-in-container'?

> It’s also a bit troubling
> that ‘eval/container’ returns an exit status instead of the evaluation
> result, but I think it has to be this way, more or less.

I haven't looked at your code, but have you considered supporting
return values that can be serialized via 'write' and then using 'read'
on the host side?  (Hmm, I wonder how exceptions could be passed from
container to host.)

Anyway, nice work!

- Dave
Ludovic Courtès July 15, 2019, 3:51 p.m. UTC | #2 
Hello!

"Thompson, David" <dthompson2@worcester.edu> skribis:

> On Mon, Jul 15, 2019 at 10:22 AM Ludovic Courtès <ludo@gnu.org> wrote:

[...]

>> I wonder if we should target ‘run-in-container’ instead of
>> ‘call-with-container’, or maybe both.
>
> I am behind the times. What is special about 'run-in-container'?

I actually meant ‘run-container’, which is the lower-level procedure
that ‘call-with-container’ invokes: it returns the PID of the process
that has been created.

>> It’s also a bit troubling
>> that ‘eval/container’ returns an exit status instead of the evaluation
>> result, but I think it has to be this way, more or less.
>
> I haven't looked at your code, but have you considered supporting
> return values that can be serialized via 'write' and then using 'read'
> on the host side?  (Hmm, I wonder how exceptions could be passed from
> container to host.)

I did that in ‘container-excursion*’ a while back, but it’s not
generally applicable (there needs to be a read syntax for what’s sent),
and I think it might be better to build it on top of a more primitive
procedure like this ‘eval/container’.

Whether we need something like this will depend on use cases I guess…

Thanks for your feedback!

Ludo’.
Ludovic Courtès July 19, 2019, 9:55 a.m. UTC | #3 
Pushed!

Ludo’.