Re: Running IceCat in a container

[Ludovic Courtès]

Heya,

Mike Gerwitz <address@hidden> skribis:

> On Thu, Jan 25, 2018 at 23:16:47 +0100, Ludovic Courtès wrote:
>> If you drop the attached file under guix/scripts/, you can then run:
>>
>>   guix run icecat icecat
>>
>> and similar.  This particular example doesn’t work well because of the
>> font issue you’re familiar with, but you get the idea.  :-)

I also realized that we can support:

  guix run icecat

which looks up ‘icecat’ in $PATH, and “readlink -f” to get at the
underlying store item.  This would be faster (and probably more
convenient) than “building” icecat as the script currently does.

> I sent a few patches moments ago that I've been sitting on for a
> bit.  My intent was originally to go further, but I ran out of
> time.  But I didn't think `guix environment' was the appropriate place
> to put such things---this script, though, is a good starting point for
> them.

Agreed.  I like the ideas in the patches you sent, but I’m not sure
‘guix environment’ is the right place for them.  It goes beyond the
typical job of ‘guix environment’.

> For example, if one of the dependencies of a program is X11, it can
> automatically share the X paths (unless overridden by the user).  Same
> with DBUS, sound devices, etc.  I mentioned previous ideas earlier in
> the thread.

Indeed, that’s a good idea.  It may be good enough to pattern-match the
store file names.

The attached version follows this suggestion:

--8<---------------cut here---------------start------------->8---
address@hidden ~/src/guix$ ./pre-inst-env guix run xdpyinfo |head

name of display:    :0.0
version number:    11.0
vendor string:    The X.Org Foundation
vendor release number:    11906000
X.Org version: 1.19.6
maximum request size:  16777212 bytes
motion buffer size:  256
bitmap unit, bit order, padding:    32, LSBFirst, 32
image byte order:    LSBFirst
address@hidden ~/src/guix$ ./pre-inst-env guix run ls -la .

total 0
drwxr-xr-x 2 0 0 40 Jan 29 16:40 .
drwxr-xr-x 3 0 0 60 Jan 29 16:40 ..
--8<---------------cut here---------------end--------------->8---

For some reason IceCat and Evince crash with a GDK error, whereas GIMP
and Xpdf are fine.

> I'd also want to integrate changes I made to `guix environment'.  If
> people here like the changes and they are merged, I'd want to refactor
> it into a common place, not just copy the code.

Yes, it’d be nice to have a module of utilities for environment
management.

>            ;; container script to invoke IceCat
>            (mkdir-p bin-dir)
>            (call-with-output-file (string-append bin-dir "icecat-container")
>              (lambda (port)
>                (format port "#!/bin/bash")))
>
>            ;; fontconfig configuration
>            (mkdir-p fc-dir)
>            (call-with-output-file fc-mtg
>              (lambda (port)
>                (format port (string-append "<?xml version=\"1.0\"?>
> <!DOCTYPE fontconfig SYSTEM \"fonts.dtd\">
> <fontconfig>
>   <dir>" (string-append (assoc-ref %build-inputs "font-dejavu")
>                         "/share/fonts") "</dir>
>   <cachedir>" fc-cache-dir "</cachedir>
> </fontconfig>\n"))))
>
>            (setenv "PATH"
>                    (string-append (assoc-ref %build-inputs "fontconfig")
>                                   "/bin"))
>            (setenv "FONTCONFIG_FILE" fc-mtg)
>            (setenv "XDG_DATA_HOME" share-dir)
>
>            (mkdir-p cache-dir)
>            (invoke "fc-cache" "-fv")))))

Nice!

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.

Food for thought!

Thanks,
Ludo’.