Change:
Cc: First of all, thanks to everyone for working on NixOS. Awesome 4.3 has a module called , it allows It can be used for theming, as shown in . However, the current build does not include the typelib files needed by the module making it unusable. The  implementation uses lgi to obtain via gobject-introspec return require('lgi').Gtk Since the current build does not include the typelib files needed, the above call fails. After some experimentation, I found out that both and are needed. For example: and try to load Gtk: fails with (the package that actually includes the typelib file) and add the folder to the environment variable: fails with and add it to and finally loads. Awesome as window manager to load the example gtk theme awesome the warnings issues by Awesome: I suggest that both and are as build inputs to the awesome package, I tried this out and it actually works. The catch is that the closure size increases by 123.9M: build awesome without gtk3-x11 and atk -99.6M build awesome with gtk3-x11 and atk -223.4M So, instead of adding the packages unconditionally, we could add an optional flag, like e.g. , defaulting to false. In this way, one could always build awesome and add it to . Ideally one could even add something like to the top level , a bit like : If a decision is made, I'd be happy to submit a PR. system: host os: multi-user?: sandbox: version: channels(root): channels(user): nixpkgs: awesome 4.3 (Too long) Compiled against Lua 5.2.4 (running with Lua 5.2) D-Bus support: execinfo support: xcb-randr version: 1.6 LGI version: 0.9.2
It should not be necessary to use , should work just fine. See for docs on , which will populate the environment variable automatically.
Thanks, I'll have a look. For the record, I used because that's where told be the typelib files where. I am still keen on hearing what the correct solution would be regarding how to add support (closure size, optional arguments etc.). Thanks.
thanks for our suggestions. Here are my thoughts: seems to work as well, the closure size is 222.9M instead of 223.4M seems quite conveniet, but awesome needs additional options in the wrapper and it's unclear to me whether we could do that after introducint uses that seems to have negative effects, see so we may have to look for alternative solutions anyway (Awesome does not seem to use much of GTK anyway as it's not a GTK app)
how could it shrink? can use as described in the doc PR to add more options. , I am aware of that but other than hardcoding the typelibs like we do in GNOME Shell extensions, we do not have anything better at the moment. See for deeper analysis.
¯()/¯ maybe it's got less dependencies built than the one? I see, I somehow missed that. It seems that works OK (I am using this in an overlay on NixOS waiting for the patches to land in the stable channel): In the end, AwesomeWM should not need the whole of gtk, I think that gtk should be made optional so one can turn it on or off. Thanks, I did notice that and I'll keep an eye on it

Discussion:
, libxkbcommon, xcbutilxrm, hicolor-icon-theme , asciidoctor , fontsConf <ins> , gtk3Support ? false, gtk3 ? null </ins> }: <ins> # needed for beautiful.gtk to work assert gtk3Support -> gtk3 != null; </ins> with luaPackages; stdenv.mkDerivation rec { name = "awesome-${version}"; version = "4.3";

xorg.libXau xorg.libXdmcp xorg.libxcb xorg.libxshmfence xorg.xcbutil xorg.xcbutilimage xorg.xcbutilkeysyms xorg.xcbutilrenderutil xorg.xcbutilwm libxkbcommon <del> xcbutilxrm ]; </del> <ins> xcbutilxrm ] ++ stdenv.lib.optional gtk3Support gtk3; </ins> #cmakeFlags = "-DGENERATE_MANPAGES=ON"; cmakeFlags = "-DOVERRIDE_VERSION=${version}";

LUA_PATH  = "${lgi}/share/lua/${lua.luaversion}/?.lua;;"; postInstall = '' <del> # Don't use wrapProgram or or the wrapper will duplicate the --search </del> <ins> # Don't use wrapProgram or the wrapper will duplicate the --search </ins> # arguments every restart mv "$out/bin/awesome" "$out/bin/.awesome-wrapped" makeWrapper "$out/bin/.awesome-wrapped" "$out/bin/awesome"