Hi Konrad,
Konrad Hinsen <konrad.hin...@cnrs.fr> skribis:
> In the long run, I'd rather have "personal Guix". Or maybe call it
> "guik", the little-used singular of "guix" ;-) Meaning Guix running
> entirely in a user's home directory. If you want a sandbox, just create
> a new user account for it. Unlike the Docker workaround, it would be
> efficient enough for real work. And it would make Guix a realistic
> alternative to Conda for many people.
I’m interested in this use case, but there’s still a couple of open
issues.
Right now, running:
guix pack -R guix --localstatedir --profile-name=current-guix
gives you a relocatable Guix tarball that you can extract in $HOME and
then run, say:
GUIX_STATE_DIRECTORY=$HOME/var GUIX_LOG_DIRECTORY=$HOME/var/log \
./bin/guix-daemon &
GUIX_DAEMON_SOCKET=$HOME/var/daemon-socket/socket \
./bin/guix build hello
This needs more testing and streamlining, so you don’t have to set three
environment variables and to manually start the daemon.
But then, the problem is that ‘guix pull’ or in fact any ‘guix’ command
will give you non-relocatable binaries. So you need to somehow map,
say, ~/.local/state/guix/store to /gnu/store for all the user sessions,
as seamlessly as possible.
I think user systemd instances could save us: it might be that we can
provide a per-user .mount file that would bind-mount the store. But
again, this needs to be tested to see if it can actually work.
If a systemd user mount is not an option, then we could provide a
‘guixify’ statically-linked binary that would spawn $SHELL in a mount
namespace where /gnu/store is available. But needless to say, that’d be
much less convenient.
Thoughts?
Ludo’.
