Hi list, For some project (yet to early to be released), I needed some specific POSIX bindings (ie. not bound in lposix nor luaposix) and I started my own posix module, which I installed system-wide manually. I was also using LuaRocks independently for different purposes. Just a few days ago I updated my whole system which brought a new version of LuaRocks (some 2.x to 2.0.3), which stopped working. I then realized that LuaRocks is using a 'posix' module, with a different API than mine.
I don't know exactly if LuaRocks added the dependency on posix recently, or if I simply didn't use it between the moment I installed my own and the system upgrade, but the situation triggers a few questions. First, how is namespace conflict handled by LuaRocks? Would I be able to publish a rock for my own posix module? I first assumed that since the 'posix' namespace is "taken", I would have to use a new one for my module. But then I realized that there are already two rocks which use it, lposix and luaposix. After a quick test, it appears I can install both concurently on my computer, is that normal? It seems the last one installed is used, but when I remove it the previous one get "un-shadowed". So some care is taken to handle conflicts, but it looks pretty arbitrary (I'm using Archi Linux, and pacman's behavior, refusing to install several packages that provide the same dependency, easier to deal with). But my real concern is about the use of posix by LuaRocks. It depends on one of these posix modules (lposix, luaposix, my own), and may or may not work with the others (it doesn't work with mine). The problem is the fact that LuaRocks uses the one installed on the system, which it will itself modify. This could result in a situation where LuaRocks stop working because of a module it installed itself, and then would be unable to remove. So my question is, why isn't LuaRocks using its own copy of whatever Lua modules it needs, so that it's freed of the potential issues I explained? I think it would make sense that LuaRocks has an independent copy of all its Lua runtime, just to make it more resilient to whatever funky stuff a user would like to do with it. Doub. _______________________________________________ Luarocks-developers mailing list [email protected] http://lists.luaforge.net/cgi-bin/mailman/listinfo/luarocks-developers
