Heya, Mike Gerwitz <m...@gnu.org> 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--- ludo@ribbon ~/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 ludo@ribbon ~/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’.