On 2023-11-16 16:23:00 +0100, Ludovic Courtès wrote: > Hi, > > Maxim Cournoyer skribis: > > > Felix Lechner writes: > > [...] > > >> How about a 'remote-user-profile'? > > > > 'guix package' is already the command we use to create profiles; maybe > > it could accept a '--remote' argument to operate on a remote machine? > > Or is this not what 'GUIX_DAEMON_SOCKET=ssh://your-target guix package > > -m manifest.scm' can already accomplish? :-) > > Doing that confuses ‘guix package’ because it’d try to perform the > effectful part (switching symlinks) locally, even though everything was > built on another machine. (It’s also slow due to RPC round trips, as > Efraim wrote.) > > But yeah, I think we could do something along these lines by isolating > the effectful bits and evaluating them remotely when needed, like we did > to achieve code sharing between ‘guix deploy’ and ‘guix system > reconfigure’. > > That said, I wonder if this would really be more convenient than SSH’ing > into the target machine and running the commands right there. Perhaps > I’m missing something about the use case? I was following the debate, but maybe I have missed something, so I will put forward my use case as well. I have two properties I would like to have from a "remote deploy" mechanism, and they are not satisfied by SSH-ing to the machine and running the commands there. 1. No need for `guix pull'. I run (a little) custom Guix, so running `guix pull' is somewhat expensive. I do not want to do it just to deploy something (be it a system, or home, or profile). 2. No need to copy over the definitions. My configurations are part of a git repository, which I would like to keep local to just my development machine. So rsync-ing it over to the remote machine in order to run command there is something I would like to avoid. If, however, I can build a profile locally, `guix copy' it over, and *then* SSH into the machine and somehow activate the profile (be it home or regular profile), that would work for me. Is that currently possible? > > Ludo’. > Thanks, Tomas -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.