Recommend using distro packages

[psychon]

See the recent problems with broken LGI installations for reasons why.

CC @Elv13 @blueyed

---

Another (additional) idea: i3 offers a repository for debian and ubuntu with their latest version: http://i3wm.org/docs/repositories.html I did not look too closely yet, but these images seem to be built on travis and then deployed to bintray (whatever that is...).

We could do the same thing, but might have to ship packages for more than just awesome. Currently for Travis on Ubuntu Trusty we "just" need libxcb-cursor-dev, xcb-util-xrm and lgi (ldoc is not a run-time dependency).

CC @AirBlader just in case there's something to add.

(Yes, I know that I should feel bad for (ab)using a pull request for a discussion that rather belongs into an issue. No, I do not actually feel bad.)

[psychon]

Another random idea: Can we make awesome available via LuaRocks? That could also solve the "LGI not found" problem (or at least: Turns it into LuaRocks' problem ;-) ). @hishamhm Can you give us some pointers here? I know that LuaRocks can install libraries and can also do binaries which are written in Lua. How about something like awesome where the main entry point is in C? From a quick look around, it seems like this is not possible...

[Elv13]

I can generate .deb for Debian, Kubuntu, Neon and a bunch of other for every commit and PR builds. My own Jenkins already has the correct Dockerfiles to do it, including for Awesome. I guess I could generate RPMs too. However if we do that, dumping Travis for BlueOcean would be preferred. The good part about this is that my CI can probably brute force the build in seconds instead of 10 minutes. No need for a PPA, I can host the repositories on my domain or an awesomewm.org subdomain redirecting to it.

BlueOcean is a much prettier CI than travis https://www.google.ca/search?biw=1859&bih=941&tbm=isch&sa=1&btnG=Search&q=blueocean+jenkins and both are compatible with Dockerfiles based builders, so switching back to Travis would be rather easy if the need arise.

[hishamhm]

Another random idea: Can we make awesome available via LuaRocks? That could also solve the "LGI not found" problem (or at least: Turns it into LuaRocks' problem ;-) ).

In GoboLinux, we install Awesome via the system's usual packaging method and LGI via LuaRocks. Since we're shipping Awesome by default, everything is there (libgobject-introspection, etc.) so there are of course no user issues. But I've seen LuaRocks users in other platforms complaining when they try to install some rock that depends on LGI due to it not finding libgobject-introspection. Installing libgobject-introspection of course is the system's package manager task, so LuaRocks can only go so far. LGI itself uses a Makefile to build, so I believe it should detect if the libraries or headers are not installed (though I'm not fully sure if it does properly). So, in short, the chain goes like this:

• During build, Awesome should check for LGI
• LGI is installable via LuaRocks or distro packages
• During build, LGI should check for libgobject-introspection
• libgobject-introspection is installable via distro packages

So, shifting all integration burden to the downstream distro packagers is of course the most hassle-free option for both upstream devs and users, but putting my downstream-packager hat on, I think each component should check for its dependencies as well.

@hishamhm Can you give us some pointers here? I know that LuaRocks can install libraries and can also do binaries which are written in Lua. How about something like awesome where the main entry point is in C? From a quick look around, it seems like this is not possible...

I originally designed LuaRocks for libraries, but it can also install pure-Lua apps due to user request. I'm afraid making it support building and installing C apps that link to Lua would be stretching it a bit to far, and make it essentially a full-fledged general-purpose package manager. But Awesome could make use of LuaRocks to install its needed dependencies, for example (check if LuaRocks is installed and then use that to install LGI, LFS, etc if they're not already installed? That's an option.)

[psychon]

@hishamhm Thanks! I actually forgot that LGI has some non-Lua dependencies that also can cause problems. Few people with that problem showed up here. So, perhaps another approach would be: Make it easier for awesome to find a LuaRocks-installed LGI. My problem with LuaRocks was that I first need eval $(luarocks paths) or the like, and always forget to do it. Perhaps we could detect the environment variables that this sets up and hardcode them in the awesome binary? (I really am trying to avoid "let's just provide distro packages" since there are sooooo many distro packages and that adds new infrastructure that needs ongoing maintenance...)

[actionless]

@Elv13

The good part about this is that my CI can probably brute force the build in seconds instead of 10 minutes.

are you going to use some premium subscription which are you using already for other project or why there is such speed-up?

[blueyed]

I understood it would be because of using (pre-built/cached) Docker images for the dependencies?!

[psychon]

I took a closer look at LuaRocks and since version 2.1.0 (from 2013) there is luarocks path --lr-path and luarocks path --lr-cpath. If I understand this correctly, we "just" have to add the results of these commands to package.path and package.cpath so that awesome can find lgi installed through LuaRocks.

So the question is: How can we do that? We would need some "luarocks" mode, I guess (awesome --use-luarocks?)... Or should we just auto-magically do that when LuaRocks is available during compilation? Or at runtime? Add something that queries these to the default config so that there is less magic going on behind people's back?

(Eventually I should move this discussion to a proper issue instead of having it here...)

[actionless]

@psychon @hishamhm but shouldn't those paths be managed by a system package with luarocks, ie smth like:

$ cat /etc/profile.d/luarocks.sh
LUA_PATH=LUA_PATH:$LUA_ROCKS_PATH
LUA_CPATH=LUA_CPATH:$LUA_ROCKS_CPATH

[blueyed]

@actionless Good point. But a) at least Arch does not do it for its luarocks package, and b) I assume that luarocks is more often installed manually than through the package manager? And when installing luarocks through the distro, then often lgi is provided there, too probably?!

[psychon]

@actionless See for example https://github.com/awesomeWM/awesome/issues/1757#issuecomment-307632151 where someone actually tried to use LuaRocks to get LGI.

For everyone: How about the following (as a first idea, if we actually merge this, I think I would move it into some module in gears; also so far I only tested this superficially).

diff --git a/awesomerc.lua b/awesomerc.lua
index 7b14754..376d427 100644
--- a/awesomerc.lua
+++ b/awesomerc.lua
@@ -1,3 +1,35 @@
+do
+    local have_lgi = pcall(require, "lgi")
+    if not have_lgi then
+        io.stderr:write("E: require('lgi') failed, "
+            .. "checking if lgi is available through LuaRocks\n")
+        -- Check if LGI was installed through LuaRocks:
+        -- Just add the LuaRocks paths to Lua's search path
+        local function read_and_add(command, key)
+            -- Using io.popen blocks awesome and is almost always a bad idea,
+            -- because via lgi we can have non-blocking mechanisms (see
+            -- awful.spawn). However, we don't have lgi yet, so popen is ok.
+            local out = io.popen(command)
+            if not out then
+                return
+            end
+            local result = out:read("*a")
+            out:close()
+            if result ~= "" then
+                package[key] = package[key] .. ";" .. result
+            end
+        end
+        read_and_add("luarocks path --lr-path", "path")
+        read_and_add("luarocks path --lr-cpath", "cpath")
+        have_lgi = pcall(require, "lgi")
+        if have_lgi then
+            io.stderr:write("...Yup, found lgi\n")
+        else
+            io.stderr:write("...Nope, require('lgi') still fails\n")
+        end
+    end
+end
+
 -- @DOC_REQUIRE_SECTION@
 -- Standard awesome library
 local gears = require("gears")

@hishamhm Do you think the above should work? Edit: I mean in general. It works here for me, but perhaps it is a bad idea.

During build, Awesome should check for LGI

It does. The following runs during build and aborts the build if it fails: https://github.com/awesomeWM/awesome/blob/master/build-utils/lgi-check.sh (However, this uses the Lua interpreter and we could be compiling against a different Lua version than what the interpreter provides... Sigh.)

[actionless]

@psychon but i guess he wasn't extending those env vars

[psychon]

@actionless Which indicates that it might make sense to make it easier to "set those env vars", which is basically what I am trying to do with my patch (just without actually setting any env vars). Edit: Added missing "make".

[blueyed]

@psychon I like your approach.

[actionless]

i still would be interested to know opinion of luarocks developer on that, because from the first glance fixing that thing on luarocks [distro package] level makes more sense to me than having it on app level

[psychon]

@actionless What exactly would you like to change in luarocks? Creating /etc/profile.d/luarocks.sh is not an option since there are non-root installations. Also, I guess they would also need an approach that works on Windows. But sure, I'm also eager for @hishamhm to tell me that my patch is not a good idea. :-) (I'll also CC some other people who regularly work on LuaRocks, just in case: @mpeterv @Tieske)

[actionless]

yes, for make install way it wouldn't work (i guess it's not ok to install some system configs, like to /etc/profile.d, with that kind of installation, right?)

but still i am convinced what that will be a more general solution to a problem because it will address it not only for awesome but for any lua scripts (so mb both need to be done)

[psychon]

I took another look at the LuaRocks wiki: https://github.com/luarocks/luarocks/wiki/Using-LuaRocks#rocks-trees-and-the-lua-libraries-path (second half of that page). It says that packages installed to the system rock tree should work by default, but for the user rock tree you have to set LUA_PATH and LUA_CPATH. Then this explains luarocks path and even recommends adding that to .bashrc.

Given the above, I guess that LuaRocks does pretty much all that they can do. At least I have no suggestion for improvement. The only problem (for us) is that a window manager is special and their suggested solution does not work here.

(so mb both need to be done)

My plan would then be to wait a bit and if no complaints / better ideas show up, I'll turn my io.popen("luarocks") patch into a pull request.

[actionless]

mb it would be better then to move that code to some of the modules instead of having it directly in rc.lua?

so in rc.lua it will be only smth like: require("awful.util").use_luarocks_path() or so on

[Elv13]

are you going to use some premium subscription which are you using already for other project or why > there is such speed-up?

No, I mean literary. I have a CI http://imgur.com/a/hPGm3

Here, electricity is very cheap. 1/5 of what you pay (or better). Why bother with co-loc fees. It cost me something like 0.02euro per hour when it's up.