Fix a race condition between Lua and LuaRocks

[sage-etcher]

Lua and LuaRocks both set (overwrite) the LUA_PATH variables, meaning which ever's Environment file is sourced last, is the only one taken into account. This fixes that for Lua >= 5.3.0 and LuaRocks >= 3.0.1 by making the change to append their paths instead of overwriting.

w/o this some packages fail to build when they need to use LuaRocks modules, one example is Awesome 4.3

#128

[Nuc1eoN]

To me it makes sense, not sure why it was set to overwrite the LUA_PATH varables. I suppose it was an oversight.

But since @hishamhm is our LuaRocks guru and created the recipes, I'm gonna let him be the judge :)

[hishamhm]

Yes, the changes make sense! I don't recall the context where this came to be, but most likely the Lua and LuaRocks recipes were made at different times, and most likely I didn't catch this behavior because I'm always running some weird in-development version of LuaRocks.

One small note is that the ;; has special meaning in Lua, meaning "expand the hardcoded defaults here". If I'm reading the changes in this PR, the Lua recipes are prepending and adding a ; in the end, and the LuaRocks recipes are appending and adding a ; at the front. This will produce a ;; in the middle. Lua's hardcoded defaults are usually pretty standard /usr or /usr/local based paths, though, so these paths should turn out to be equivalent to our /System/Index paths and all should work well. So that's probably harmless, so +1 from me on this PR!

(Speaking of Lua and LuaRocks recipes, one quirk that happens in my — admittedly very outdated — Gobo machine is that my Awesome installation requires /Programs/Lua/Current to be Lua 5.3, and if I switch my Current to Lua 5.4, Awesome fails to start up (I think it links to liblua.so instead of liblua.so.5.4 or similar?), so whenever I need to switch Lua versions, I end up using SymlinkProgram to switch temporarily and then back. I can't verify exactly the details of the behavior is because I currently don't have access to my Gobo machine (don't worry, I'm safe) )

[sage-etcher]

One small note is that the ;; has special meaning in Lua, meaning "expand the hardcoded defaults here".

Interesting note! I wish I could take credit and say it was intentional, but it wasn't- though it's good to know, thanks! =DD

my Awesome installation requires /Programs/Lua/Current to be Lua 5.3, and if I switch my Current to Lua 5.4, Awesome fails to start up (I think it links to liblua.so instead of liblua.so.5.4 or similar?), so whenever I need to switch Lua versions, I end up using SymlinkProgram to switch temporarily and then back.

Yes, I've been looking into this exact issue. It's due to the lua_newuserdata function from 5.3 being changed to a preprocessor macro in 5.4. Recompiling Awesome fixes the issue, so long as you have the needed Luarocks modules installed for Lua54.

The full thread on the issue can be found here at issue #128.

[Nuc1eoN]

I can't verify exactly the details of the behavior is because I currently don't have access to my Gobo machine (don't worry, I'm safe) )

Oh gosh! Can't believe have been a victim of that.. Glad that you're safe 👍

---

About the Lua 5.4 issue with Awesome, yes as pointed out we are working on that in #12, and this PR here is part of that effort. It has been quite a rabbit hole.

Thank you for the review of this PR :)