Ricardo Wurmus <[email protected]> writes: > myglc2 <[email protected]> writes: > >> The use case I had in mind is that sysadmin uses Guix to provide a >> specific Guix environment to support 1 or more "dumb" application users >> (e.g, provide a stable specific version of R to a project team for the >> duration of the project). In this case sysadmin does not want to burden >> the team members with learning Guix. >> >> Do we support such a case? > > Yes. I have been doing this for our cluster users for months before we > could make the changes in our environment that were needed to let users > manage their profiles by themselves. > > We currently use Guix for shared per-group profiles, individual per-user > profiles, and per-project profiles. > > You can install packages into a custom profile by using the “-p” flag, > e.g. > > guix package -p /path/to/shared/profile \ > --install glibc-utf8-locales r r-genomation > > Users would then have to add something like this to their > ~/.bash_profile: > > eval $(guix package -p /path/to/shared/profile --search-paths=prefix) > > or just add the result of the command in parentheses to the > ~/.bash_profile. This would prepend the “bin” directory of the profile > to the PATH and set other environment variables that are needed. > > Then they could use an unchanging version of the “genomation” package > from within R, as defined in that profile. (In the long run it would > make more sense to instantiate profiles using manifest files.)
Fantastic. You have just described one of the fantasy use cases that have propelled me to spend a few weeks learning first NixOS and now Guix. > Slightly off-topic: note that in this case installing R packages via > ‘install.packages(...)’ is discouraged. Some R packages link with > system libraries and unless you’re also adding the compiler toolchain to > your profile you would end up with binaries that are linked with the > system libc and thus cannot successfully be loaded by the R in your > profile, which is linked with libc from the Guix store. > > I suggest going full Guix instead of mixing ‘install.packages(...)’ with > Guix stuff. We have importers for CRAN and bioconductor, so packaging R > packages for Guix is usually really simple. (I’ve used the importer to > generate package expressions for all of CRAN, but since I’m not using > them all I haven’t yet found motivation to submit patches for them.) I have bite marks from the same dog. I agree this is the way to go. >>>> 4) What do we mean by, 'The guix package must remain available in root’s >>>> profile, or it would become subject to garbage collection—in which >>>> case you would find yourself badly handicapped by the lack of the >>>> guix command.' >>>> >>>> What does root have to do to assure that 'The guix package remains >>>> available'? >>> >>> I think this means that the root user should not uninstall guix with >>> guix. >> >> "Thompson, David" <[email protected]> writes: >> [...] >>> >>> Don't run 'guix package -r guix'. >> >> Cool, please say that. > > +1! > >> Ricardo Wurmus <[email protected]> writes: >> [...] >>>> 5) We should tell root how to verify that the installation was >>>> successful. If 'make guix-binary.system.tar.xz' is intended to do >>>> this, we need to explain where to run it and how to verify the >>>> result. >>> >>> The install was successful if “guix package -i hello” (or similar) >>> works. >> >> Cool, lets tell them to do that. > > +1! > > Would you be willing to send a patch? (I’m pretty sure I’ll forget > doing this myself.) Will do once I get my Guix space suit fully inflated ;=)
