guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Using Guix inside a Guix container


From: Ludovic Courtès
Subject: Re: Using Guix inside a Guix container
Date: Tue, 21 Feb 2023 23:50:16 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)

Hello!

Konrad Hinsen <konrad.hinsen@fastmail.net> skribis:

> I have been playing with nested Guix containers recently, with some
> suprising findings, and I am wondering if what I am doing is considered
> officially supported or not.
>
> First: why? My use case is scientific workflows, for example using
> snakemake. I want to run my workflows in Guix containers, for
> reproducibility plus other reasons. But my workflows run other programs
> in their tasks (basically just "shelling out"), and those tasks may use
> their own Guix containers.

That’s an interesting use case!  I guess we have a hard-enough time
getting the message through regarding the environment of tasks that we
didn’t really consider the environment of the “driver”.

(Well, in a way, GWL and Guix-Jupyter sidestep the issue by integrating
the mechanism to declare task environments.)

> Superficially, this works fine if I add the "guix" package to my "outer"
> container and expose the store plus the daemon's socket:
>
>     guix shell -C guix \
>       --expose=/var/guix/daemon-socket/socket \
>       --expose=/gnu/store \
>       -- \
>       guix shell -C coreutils -- ls /

I wasn’t sure ‘--expose=/gnu/store’ would even work… but it does!  Kinda
by chance though.

The thing is that ‘-C’ bind-mounts just the subset of the store that’s
needed.  To support nested containers, we need to bind-mount the whole
store because new store items may pop up in there over time.

I’d be inclined to add a new ‘-W’ (say) option to (1) share the whole
store, and (2) share the daemon socket.  That would be the documented
way to create a container with support for nested containers.


[...]

> Great! Except that every time I run this command, it does the channel
> update from scratch, so it's prohibitively slow. Sharing
> ${HOME}/.cache/guix seems to fix that. So... finally...
>
>     guix shell -C -N guix nss-certs \
>       --expose=/var/guix/daemon-socket/socket \
>       --expose=/gnu/store \
>       --share=${HOME}/.cache/guix \
>       -- \
>       guix time-machine -C channels.scm \
>       -- \
>       shell -C coreutils \
>       -- \
>       ls /
>
>      guix shell: error: mount: mount "none" on
>      "/tmp/guix-directory.vpOEDC/sys": Operation not permitted

That one’s interesting.  Reported here:

  https://issues.guix.gnu.org/61690

At least there’s a workaround: using ‘-CN’ in the nested container.

Ludo’.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]