On Wed, Oct 13, 2010 at 10:28 AM, <[email protected]> wrote: > This means (i.e. it's a feature, not a bug) that it doesn't > detect installed modules. E.g. if I've done aptitude install > liblua5.1-posix1 > in order to get a version of luaposix less out-of-date > the 5.1.2 offered as a rock, then luarocks list can't see it.
Oh dear, I was hoping that lposix would win that particular namespace war ;) > luarocks longlist .. would just traverse the require-path reporting all > modules. It would be better and more consistent if such 'foreign' libraries were registered with the system, so that they would appear as valid dependencies. So I could imagine a 'luaposix-debian' rockspec which used aptitude, but how then would it register the module? I think that's a solvable problem, however. Another very important example is Wolfgang Oertl's excellent Lua-Gnome, which is available as liblua5.1-gnome-0 on Debian/Ubuntu repos. I would love to be able to release apps through LR which depended on this, but it would need some thinking about how to formally register with LR the modules installed by this native package. > and version-conflicts, and which file will actually get invoked > by a "require". We had this recently with lposix/luaposix - they're both 'require 'posix'' and the one you get depends entirely on the order of installation, unless you're using luarocks.require on the local tree. Not an ideal situation for someone wanting to create a rock which depends on this functionality, and a logical consequence of LR's new convenience ;) steve d. _______________________________________________ Luarocks-developers mailing list [email protected] http://lists.luaforge.net/cgi-bin/mailman/listinfo/luarocks-developers
