I wrote:
> luarocks longlist .. would just traverse the require-path
> reporting all modules.
require 'posix'
for k in string.gmatch(package.path, '[^;]+') do
local g = posix.glob(string.gsub(k, '\?', '*'))
if g then print(table.concat(g, "\n")) end
end
Hmm, it's not as easy as traversing package.path like I dreamed;
e.g. aptitude install liblua5.1-posix1 leaves its posix in
/usr/lib/lua/5.1/posix.so --> /usr/lib/liblua5.1-posix.so.1.0.0
which is not in the package.path
But, internally, Lua knows where to look for its modules...
Is there an equivalent to package.path which would include
the places where its *.so modules live ?
steve donovan wrote:
> It would be better and more consistent if such 'foreign'
> libraries were registered with the system, so that they
> would appear as valid dependencies.
Ignoring the depends-on-particlar-version problem, I think
a pragmatic way is just to look at what's on the filesystem.
That's what Lua does when it runs...
But versions :-( Mandating a
MyModule.Version='98.7' in the modules themselves would
be hard to impose. So, giving up on the version-information
of the "just cp a Lua module into your LUA_PATH" modules:
Maybe luarocks could peek into /var/lib/dpkg and its rpm and
windows equivalents ? (too pragmatic? too high-maintenance?)
> I could imagine a 'luaposix-debian' rockspec which
> used aptitude, but how then would it register the module?
There might be some hope of persuading dpgk, rpm and windows
package-maintainers to invoke luarocks register posix 5.1.4
in their post-install scripts ?
They a finite in number, and they are Luafolk...
Peter
http://www.pjb.com.au [email protected] (03) 6278 9410
"Was der Meister nicht kann, vermöcht es der Knabe, hätt er
ihm immer gehorcht?" Siegfried to Mime, from Act 1 Scene 2
_______________________________________________
Luarocks-developers mailing list
[email protected]
http://lists.luaforge.net/cgi-bin/mailman/listinfo/luarocks-developers
