Ricardo Wurmus <rek...@elephly.net> skribis: > Ludovic Courtès <l...@gnu.org> writes: > >> Actually there are really two approaches we could use. One is to create >> wrappers like this one that do the right thing, independently of what >> the user’s profile contains (‘guix package’ could even generate wrappers >> automatically in some cases.) >> >> The second approach is a ‘guix run/environment’ kind of command that >> generates the environment at run time. >> >> There are pros and cons to both, I think. > > This is just a tangent: > > I’ve been thinking that “guix run” (or an extension of “guix container”) > would be great not only for running applications in containers that are > *already* in the store, but also to run applications from tarballs that > were generated with "guix pack“. > > pack=$(guix pack $(readlink -f $HOME/.guix-profile) -S /bin=bin) > guix run --image=${pack} /bin/icecat > > Look, we’ve got our own container image format! :) This seems to cover > 85% of all uses of Docker/Singularity in the field of bioinformatics.
Indeed, very good point! > The setup to create configuration files and set environment variables so > that the target application feels at home in the container — that all > looks an awful lot like profile hooks to me. Maybe we can have a set of > common hooks that we can automatically derive from package inputs? Sounds like search paths no? Or maybe a bit of both? Anyway, it wouldn’t cost us much so to speak, so it’s worth looking into that. Ludo’.