Given a configuration like
nixpkgs.overlays = [
(self: super:
with super; {
awesome =
super.awesome.override { luaPackages = super.luajitPackages; };
})
];
services = {
xserver = {
enable = true;
displayManager.startx.enable = true;
desktopManager.xterm.enable = false;
windowManager.awesome = {
enable = true;
luaModules = with pkgs; [
luajitPackages.lgi
];
};
};
}
I would expect LGI to be installed and loaded alongside with Awesome, although
awesome 4.3 (Too long)
• Compiled against Lua 5.1.4 (running with LuaJIT 2.1.0-beta3)
• D-Bus support: ✔
• execinfo support: ✔
• xcb-randr version: 1.6
• LGI version: module 'lgi.version' not found:
no field package.preload['lgi.version']
no file './lgi/version.lua'
no file '/nix/store/kcns6qq23xnb8x041c5ihgj4x3kxzacq-luajit-2.1.0-beta3/share/luajit-2.1.0-beta3/lgi/version.lua'
no file '/usr/local/share/lua/5.1/lgi/version.lua'
no file '/usr/local/share/lua/5.1/lgi/version/init.lua'
no file '/nix/store/kcns6qq23xnb8x041c5ihgj4x3kxzacq-luajit-2.1.0-beta3/share/lua/5.1/lgi/version.lua'
no file '/nix/store/kcns6qq23xnb8x041c5ihgj4x3kxzacq-luajit-2.1.0-beta3/share/lua/5.1/lgi/version/init.lua'
no file './lgi/version.so'
no file '/usr/local/lib/lua/5.1/lgi/version.so'
no file '/nix/store/kcns6qq23xnb8x041c5ihgj4x3kxzacq-luajit-2.1.0-beta3/lib/lua/5.1/lgi/version.so'
no file '/usr/local/lib/lua/5.1/loadall.so'
no file './lgi.so'
no file '/usr/local/lib/lua/5.1/lgi.so'
no file '/nix/store/kcns6qq23xnb8x041c5ihgj4x3kxzacq-luajit-2.1.0-beta3/lib/lua/5.1/lgi.so'
no file '/usr/local/lib/lua/5.1/loadall.so'
For the sake of completeness, it’s not exclusive to LuaJIT
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: [string "return require('lgi.version')"]:1: module 'lgi.version' not found:
no field package.preload['lgi.version']
no file '/usr/share/lua/5.2/lgi/version.lua'
no file '/usr/share/lua/5.2/lgi/version/init.lua'
no file '/usr/lib/lua/5.2/lgi/version.lua'
no file '/usr/lib/lua/5.2/lgi/version/init.lua'
no file './lgi/version.lua'
no file '/usr/lib/lua/5.2/lgi/version.so'
no file '/usr/lib/lua/5.2/loadall.so'
no file './lgi/version.so'
no file '/usr/lib/lua/5.2/lgi.so'
no file '/usr/lib/lua/5.2/loadall.so'
no file './lgi.so'
It feels like no matter what, luaModules take no effect, I could even write luaModules = [ anything ]; and it won’t raise errors.
What I’m doing wrong here?
That lgi error is due to the fact awesome doesn’t consult the argument to --search we put in it’s wrapper, when you run --version. See Awesome window manager can't load GTK+3 introspection · Issue #75410 · NixOS/nixpkgs · GitHub
Note that specifically lgi is already part of the Lua packages awesome should be aware of, in order to function at all, so there’s no need for the overlay if this is it’s only task :).
Interesting, @doronbehar thank you for sharing details on the --version.
Actually it was just an example, what I’m trying to achieve is the install of dbus_proxy through a package overlay (code available here). Should’ve mentioned this before, sorry.
When I specify the package in luaModules (ref) it’s not loaded. No matter what I specify in luaModules actually, the code apparently takes no effect (I tried to force it to break passing invalid values, nothing happened).
Click here to see the logs
In case that helps, these are AwesomeWM’s error logs
2020-08-11 11:35:05 E: awesome: Error during a protected call: /home/macunha1/.config/awesome/plugins/spotify/init.lua:6: module 'dbus_proxy' not found:
no field package.preload['dbus_proxy']
no file './dbus_proxy.lua'
no file '/nix/store/kcns6qq23xnb8x041c5ihgj4x3kxzacq-luajit-2.1.0-beta3/share/luajit-2.1.0-beta3/dbus_proxy.lua'
no file '/usr/local/share/lua/5.1/dbus_proxy.lua'
no file '/usr/local/share/lua/5.1/dbus_proxy/init.lua'
no file '/nix/store/kcns6qq23xnb8x041c5ihgj4x3kxzacq-luajit-2.1.0-beta3/share/lua/5.1/dbus_proxy.lua'
no file '/nix/store/kcns6qq23xnb8x041c5ihgj4x3kxzacq-luajit-2.1.0-beta3/share/lua/5.1/dbus_proxy/init.lua'
no file '/nix/store/3cx5yimqp4sx343d3liy9q7qk0s8r5wg-luajit-2.1.0-beta3-lgi-0.9.2-1/lib/lua/5.1/dbus_proxy.lua'
no file '/nix/store/3cx5yimqp4sx343d3liy9q7qk0s8r5wg-luajit-2.1.0-beta3-lgi-0.9.2-1/lib/lua/5.1/dbus_proxy/init.lua'
no file '/nix/store/3cx5yimqp4sx343d3liy9q7qk0s8r5wg-luajit-2.1.0-beta3-lgi-0.9.2-1/share/lua/5.1/dbus_proxy.lua'
no file '/nix/store/3cx5yimqp4sx343d3liy9q7qk0s8r5wg-luajit-2.1.0-beta3-lgi-0.9.2-1/share/lua/5.1/dbus_proxy/init.lua'
no file '/home/macunha1/.config/awesome/dbus_proxy.lua'
no file '/home/macunha1/.config/awesome/dbus_proxy/init.lua'
no file '/etc/xdg/awesome/dbus_proxy.lua'
no file '/etc/xdg/awesome/dbus_proxy/init.lua'
no file '/home/macunha1/.nix-profile/etc/xdg/awesome/dbus_proxy.lua'
no file '/home/macunha1/.nix-profile/etc/xdg/awesome/dbus_proxy/init.lua'
no file '/etc/profiles/per-user/macunha1/etc/xdg/awesome/dbus_proxy.lua'
no file '/etc/profiles/per-user/macunha1/etc/xdg/awesome/dbus_proxy/init.lua'
no file '/nix/var/nix/profiles/default/etc/xdg/awesome/dbus_proxy.lua'
no file '/nix/var/nix/profiles/default/etc/xdg/awesome/dbus_proxy/init.lua'
no file '/run/current-system/sw/etc/xdg/awesome/dbus_proxy.lua'
no file '/run/current-system/sw/etc/xdg/awesome/dbus_proxy/init.lua'
no file '/nix/store/r5w3v0w834hz6c7r1g668p5zj60b8yzp-awesome-4.3/share/awesome/lib/dbus_proxy.lua'
no file '/nix/store/r5w3v0w834hz6c7r1g668p5zj60b8yzp-awesome-4.3/share/awesome/lib/dbus_proxy/init.lua'
no file './dbus_proxy.so'
no file '/usr/local/lib/lua/5.1/dbus_proxy.so'
no file '/nix/store/kcns6qq23xnb8x041c5ihgj4x3kxzacq-luajit-2.1.0-beta3/lib/lua/5.1/dbus_proxy.so'
no file '/usr/local/lib/lua/5.1/loadall.so'
no file '/nix/store/3cx5yimqp4sx343d3liy9q7qk0s8r5wg-luajit-2.1.0-beta3-lgi-0.9.2-1/lib/lua/5.1/dbus_proxy.so'
no file '/nix/store/3cx5yimqp4sx343d3liy9q7qk0s8r5wg-luajit-2.1.0-beta3-lgi-0.9.2-1/share/lua/5.1/dbus_proxy.so'
no file '/home/macunha1/.config/awesome/dbus_proxy.so'
no file '/etc/xdg/awesome/dbus_proxy.so'
no file '/home/macunha1/.nix-profile/etc/xdg/awesome/dbus_proxy.so'
no file '/etc/profiles/per-user/macunha1/etc/xdg/awesome/dbus_proxy.so'
no file '/nix/var/nix/profiles/default/etc/xdg/awesome/dbus_proxy.so'
no file '/run/current-system/sw/etc/xdg/awesome/dbus_proxy.so'
no file '/nix/store/r5w3v0w834hz6c7r1g668p5zj60b8yzp-awesome-4.3/share/awesome/lib/dbus_proxy.so'
stack traceback:
[C]: in function 'require'
/home/macunha1/.config/awesome/plugins/spotify/init.lua:6: in main chunk
[C]: in function 'require'
/home/macunha1/.config/awesome/themes/cyan-neon/theme.lua:18: in main chunk
[builtin#25]: at 0x7fd120423750
[C]: in function 'xpcall'
...p-awesome-4.3/share/awesome/lib/gears/protected_call.lua:30: in function 'protected_call'
...60b8yzp-awesome-4.3/share/awesome/lib/beautiful/init.lua:224: in function 'init'
/home/macunha1/.config/awesome/rc.lua:208: in main chunk
@macunha I’m no longer an AwesomeWM user, but I used to be, so I’m fairly familiar with all it’s quirks. I’ve even used exactly the dbus_proxy module you referred to, along with some pulseaudio related libraries by the same developer.
But, I did it via luarocks and environmental variables I had set when I ran startx - I think you’d like to setup your awesome so it’ll find these modules via --search and not via LUA_PATH? When I used external Lua modules with my AwesomeWM setup in the past I used luarocks path and imperative installation of Luarocks modules which didn’t survive garbage collections - naturally, at some point I realized it was a horrible way to manage it all, without Nix so I hope this’ll at least warn you against this path.
You might find useful this: GitHub - stefano-m/nix-stefano-m-nix-overlays: Collection of Nix overlays .
1 Like
@doronbehar you were right, setting --search inside .xinitrc (to load during startx) solved the issue. Main problem is that I’m not using a DM, therefore I have no “session” which is what luaModules parameter is configuring inside NixOS AwesomeWM module ref. The answer was right in front of me all the time 
Which means that I will have to include dbus_proxy as part of the Wrapper ref in a overlay to follow the derivations (i.e. survive garbage collections, as you mentioned). Thanks for the advice (:
BTW, I trully believe that you used to be a great AwesomeWM user (in fact the JIT overlay in the description came from your PR).
Thank you for your help, I really appreciate that
1 Like
@macunha what’s a bit confusing in the current state of things, is that both the derivation itself calls wrapProgram in a way that puts --search arguments to the wrapper, and also the xserver module adds another --search to the call of the already wrapped awesome - meaning someone can eventually have --search used both in the derivation of AwesomeWM and both in the xsession command. Not ideal, and not much override inviting.
setting --search inside .xinitrc (to load during startx) solved the issue.
That’s not a setup I’d settle on - it’s imperative. Perhaps it’d be proper to allow the derivation of awesome itself to add --search arguments to the wrapper, i.e at:
But it won’t be elegant. I plan to suggest our ecosystem a new way of wrapping that should fit all usecases in Nixpkgs, via declarative wrappers - [RFC] Declarative wrappers by doronbehar · Pull Request #85103 · NixOS/nixpkgs · GitHub . I’ll open an RFC soon.
BTW, I trully believe that you used to be a great AwesomeWM user (in fact the JIT overlay in the description came from your PR).
Thanks :).
1 Like