Hi Hisham,
Thanks for your detailed answers. I replied to some of the issues below.
> > I have a couple of questions which might become show stoppers...
> >
> > 1. How do you handle runtime dependency between modules (version matching) ?
>
> If you want LuaRocks to check version matching of dependencies at
> runtime, you need to require "luarocks.loader", which installs a
> package loader that performs that check. If you don't use use that,
> then the latest version of each installed module will be the one
> available in the Lua lookup paths.
>
>
That should work (I hope).
> > I could prefix all modules with "lubyk-zmq", so that the above require would
> > be:
> >
> > local zmq = require"lubyk-zmq"
>
> ...avoiding namespace conflicts is a much nicer approach, and would
> solve the problem for non luarocks.loader (or even non-LuaRocks) users
> as well. For aesthetic/organizational reasons, I'd recommend
> "lubyk.zmq", so your module would be installed at lubyk/zmq.so (or
> lubyk/zmq.lua).
>
>
It should be OK to alter non-luarocks installations to support this syntax
everywhere:
local zmq = require "lubyk.zmq"
> > 3. Autoload. Lubyk uses an auto-load system so when lubyk users do (without
> > other requires then "require 'lubyk'":
> >
> > local s = zmq.Socket(...)
> >
> > This automagically loads "zmq" and "zmq.Socket". I feel that this should
> > work without too many issues.
> >
>
>
> That's probably beyond the scope of LuaRocks, and should work the same
> way. One question though: how do you do that? Do you edit the global
> environment's metatable using the debug library? (Side question: Is
> that 5.2 compatible?) Some users, especially those wishing to use your
> library in conjunction to others, might take issue with that tinkering
> of the globals table. Providing an alternative that does not do the
> auto-loading may be a good idea.
>
>
The autoload feature is only started explicitly by users by either:
require 'lubyk' (instead of just the actual libraries)
OR
require 'lub'
Autoload.global()
Autoload sets a metatable on _G with an __index method. For quick scripts and
experiments, it really makes things nicer. I will
alter autoload to search for "lubyk.[module]" instead of "[module]".
> > 4. Common files needed in "includes" and build. Multiple modules use the
> > "Fifo" and msgpack code to transform OS threads into pipes. Does this mean
> > that I need to copy these common files in each rock sources ?
> >
>
>
> Interesting question. I just took a look at the lubyk tree at github,
> and it makes heavy use of git submodules, which is something that
> LuaRocks is not really aware of.
> (See this issue on why --recursive was not added:
> https://github.com/keplerproject/luarocks/issues/106 -- the main
> reason is that right now it would break rockspec compatibility)
>
> So I'm afraid that at this point you'd have to copy these common files
> in each rock sources... however, instead of duplicating them in your
> various repositories, one idea would be to write a script that
> performs the recursive fetch and packs tarballs of "release versions"
> of each module, and then write rockspecs that use these tarballs,
> instead of fetching code directly from git. How does that sound?
>
>
The sub-modules are only used when building a lubyk binary distribution or
sources based install. Copying some common files (eventually with a script)
seems OK.
In a second stage (once core parts are published), I am concerned by "wrapper"
modules like "bt" (bullet physics bindings) or "mimas" (Qt bindings). On
Windows, it makes sense to have the
sources included but on linux, users probably expect some dynamic linking. We
will see in due time....
>
> Let me know if you have any more questions and any way I can help you
> with this. Lubyk is a very intriguing project and it's really nice to
> see a complex project like this making its way into LuaRocks and
> integrating itself more with the Lua modules ecosystem.
>
>
>
Thanks for your help and work on the hidden side of the moon. I will create a
first rockspec for "lub" (documentation generator, testing) to see how it goes.
Cheers,
Gaspard
------------------------------------------------------------------------------
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete
for recognition, cash, and the chance to get your game on Steam.
$5K grand prize plus 10 genre and skill prizes. Submit your demo
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
_______________________________________________
Luarocks-developers mailing list
Luarocks-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/luarocks-developers
