guix-science
[Top][All Lists]
Advanced

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

Re: [ext] Re: guix on nfs based systems


From: Ricardo Wurmus
Subject: Re: [ext] Re: guix on nfs based systems
Date: Thu, 14 Dec 2023 20:35:25 +0100
User-agent: mu4e 1.10.8; emacs 29.1

Hi Etienne,

> I think we've arrived at the limit of how I understand the daemon to work, 
> and GUIX_DAEMON_SOCKET. I think I understand that you
> are using a single node (hpc of sort I imagine), where users create sessions, 
> and within which you provide the guix command, having
> set up GUIX_DAEMON_SOCKET to a unix-domain socket (to that same node / 
> itself). That makes total sense in the context of the single
> node. Did I get that right?

No, we provide Guix on *all* cluster nodes and workstations, but they
all talk to a single guix-daemon, which is the sole manager of /gnu.  We
provide a default Guix for all those who haven’t yet run “guix pull” at
/gnu/remote/bin/guix.  That location is on the PATH on all machines.

This script does three things:

- it sets GUIX_DAEMON_SOCKET to http://guix-node:9999
- it removes “gc” from the arguments and prints a warning (this is not
  enough to prevent GC, but it works well enough)
- it looks for the user’s “guix” in /home/who/.config/guix/current/bin;
  if it exists it execs that “guix” with the arguments; otherwise it
  executes the shared default Guix.

> The issue with profiles you are mentioning is interesting; I haven't
> quite thought it through yet. I think I would personally want users to
> be able to create profiles (for reproducibility reasons) but I guess
> it would work the same way with guix shells built from manifests,
> maybe slightly less easy to interact with, I don't know.

In my experience, profiles always end up growing in a stateful manner.
People use them to satisfy old habits of installing, removing, and
upgrading packages, and inevitably they run into conflicts because they
install new packages to a profile built with an older version of Guix.
Yes, using manifests would avoid that, but if you’re already using
manifests you might as well use “guix shell -m”.  For long-term
reproducibility we recommend recording the current channels with “guix
describe -f channels” and add the output to version control.

With “guix time-machine -C channels.scm -- shell -m manifest.scm” people
can restore the environment in the future.

-- 
Ricardo Wurmus

System administrator
BIMSB - Scientific Bioinformatics Platform
Max Delbrueck Center for Molecular Medicine

email: ricardo.wurmus@mdc-berlin.de
tel:   +49 30 9406 1796



reply via email to

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