Oops, my bad, I seemed to have hit Reply, instead of Reply-all.

Here is the follow up to that email:


*Etienne B. Roesch <etienne.roesch@gmail.com <etienne.roesch@gmail.com>>
3:42 PM (12 minutes ago) to Pierre-Antoine*
Merci Pierre-Antoine ! :)

It sounds like you also made the conscious choice of using guix shells,
instead of profiles. Why is that? I am guessing profiles have a more
widespread impact on what's available to the user, modifying paths and so
on, whereas shells would be more contained and short-lived, and therefore
"safer" for users?

I'll have to write documentation and train users either way ;)

Etienne


*Pierre-Antoine Bouttier 3:47 PM (7 minutes ago) to me*

> Merci Pierre-Antoine ! :)

My pleasure :)

> It sounds like you also made the conscious choice of using guix shells,
instead of profiles.
> Why is that?

Because

> I am guessing profiles have a more widespread impact on what's available
to the user,
> modifying paths and so on, whereas shells would be more contained and
short-lived, and
> therefore "safer" for users?

;)

Yes, indeed, the isolated and self-contained aspect of guix shell avoid to
mess with environment variables. And it’s far more easier, in a
reproducibility point of view, with manifest.scm and channels.scm to
explain to users how to work with guix time-machine and guix shell.

But, our users can use guix profile (and some of them don’t hold back).

P-A

On Thu, Dec 14, 2023 at 3:33 PM Pierre-Antoine Bouttier <
Pierre-Antoine.Bouttier@univ-grenoble-alpes.fr> wrote:

> Hi Etienne,
>
> 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.
>
>
> As part of the support team in a HPC center that provides guix command to
> our users to set up their software environments, we advice them to use guix
> shell rather than guix profile and most of them are pretty happy with that.
> Obviously, you need to write a good documentation :)
>
> My 2 cents
> P-A
> ---
> Pierre-Antoine Bouttier
> CNRS Research Engineer
> Dir. Adj. UAR GRICAD
>
> GriCAD - https://gricad.univ-grenoble-alpes.fr/
> Batiment IMAG
> CS 40700
> 38058 Grenoble CEDEX 9
>
> +33 4 57 42 18  66
>
> Le 14 déc. 2023 à 16:28, Etienne B. Roesch <etienne.roesch@gmail.com> a
> écrit :
>
> Thanks a ton!
>
> 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?
>
> I think what we are aiming for, in our case (where users each have their
> own nodes as it were, only sharing network drives), is providing the guix
> command on each node, set up with GUIX_DAEMON_SOCKET connecting with ssh to
> a master node with a daemon, that itself would have access to the same
> network drives.
>
>
> Etienne
>
> On Thu, Dec 14, 2023 at 2:48 PM Ricardo Wurmus <
> ricardo.wurmus@mdc-berlin.de>
> wrote:
>
>
> "Etienne B. Roesch" <etienne.roesch@gmail.com> writes:
>
> Hiccups: we provide home dirs as nfs drives through the network. Using
>
> guix, we are thinking of creating one nfs drive, shared by all
>
> users, to contain /var/guix and /gnu/store, symlinked from /.
> As I understand, that should work, until a user decides to run "guix gc"
>
> (which would clear wrongly assumed unused profiles) or maybe
>
> until a user decides to launch several vms (which is theoretically
>
> possible, but doesn't happen often).
>
> I would strongly discourage the use of profiles in users’ home
> directories.  When introducing Guix we now only demo “guix shell”, which
> is preferrable in most cases.  “guix gc” is problematic when profile
> links are in locations that the daemon cannot read.
>
> Efraim suggested using a shared daemon ssh-ing GUIX_DAEMON_SOCKET. We
> would probably run this on a separate vm. We are however unsure how it
> would behave when /var/guix/daemon-socket/socket is itself on an nfs.
>
>
> We only export /var/guix/profiles, not anything else in /var/guix.
> Using GUIX_DAEMON_SOCKET with a network port (make “guix-daemon” listen
> on that port) is all we ever needed.
>
> --
> 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
>
>
>