Hi Ricardo! Ricardo Wurmus <ricardo.wur...@mdc-berlin.de> skribis:
> Ludovic Courtès <l...@gnu.org> writes: [...] >> Right, I’m not sure what to do with binaries installed with this >> relocatable Guix: either we let the user run them from a relocatable >> shell that maps /gnu/store appropriately (as in the message above), >> which works but is inconvenient, or we somehow instruct ‘guix package’ >> to make everything relocatable before adding it to the profile (like >> what ‘guix pack -R’ does.) > > Installing a relocatable wrapper would be fine, too, but I think it’s a > little ugly that a profile generated with relocation enabled would > contain different binaries than one where this hasn’t been done. I > have a slight preference for keeping the software unchanged. I agree about the ugliness. > FWIW running programs in a “container environment” is what Docker users > are already used to. It would be fine to have “guix container --run …” > or a variant of the proposed “guix run” for the kinds of people who are > used to Singularity or Docker. Right, so we could have something like “guix enter” or even simply ./bin/sh (a wrapped shell that binds /gnu/store in its namespace.) >> As for spawning guix-daemon automatically, I’m not sure. I’d rather >> have the ‘guile-daemon’ branch ready and merged, and then use that as a >> library, rather than having to spawn a full guix-daemon process behind >> the scenes. Though of course, that’s a longer-term effort. > > Yes, I’m not really interested in running the daemon; it would be even > better if we could avoid it of course. But I don’t think that this can > be accomplished within a reasonable time frame. We have that depedency > on the daemon now and it seems to me that starting it automatically (in > the presence of a ’guix’ command line flag or an environment variable) > is a solution that requires the least effort. I see. (Though in terms of effort, having just the bits of the ‘guile-daemon’ branch needed for this setup may not be that much work compared to setting up the machinery to spawn ‘guix-daemon’.) > My goal really is to free the user from thinking about the daemon at > all. When the user has indicated (how?) that it is preferable to keep > the store somewhere in ~/.local and use file system virtualization, then > we could take care of the daemon and everything that belongs to it. One way to configure it might be to set GUIX_DAEMON_SOCKET=internal or something along these lines. Something that works without config would be better, but it seems difficult to achieve without breaking current multi-user setups. > If it allows users on single-user systems to use Guix easily without > having to be root then I think it would very well be worth the effort. > The dependency on a daemon that runs as root is still often considered > an obstacle — you probably also know that Singularity got a big > popularity boost purely for circumventing the need for a root daemon (by > using a setuid binary, which admins seem not to worry or know about). > Allowing people in certain situations to forget about the daemon might > have a similarly positive effect on how people perceive the setup > complexity of Guix. > > “guix pack” is great for using software on systems where Guix cannot be > used, but its output for one package closure cannot be composed with the > output of another package closure. By making the daemon run in a > container we can bring more of the features of Guix to these limited > systems. OK, that makes sense. Well, let’s see how we can get there! Thanks, Ludo’.
