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’.

Reply via email to