On 29 March 2013 06:11, Gaspard Bucher <gasp...@teti.ch> wrote: > Hi there, > > I am interested in creating rockspecs and publishing some parts (or all > parts) of lubyk. At least, I want to have "dub" (C++ binding generator) and > the auto-doc tool used by lubyk (http://doc.lubyk.org/lk.Doc.html).
Excellent! That would be great!! > 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. > 2. How to deal with namespace conflicts ? For example, I have a "zmq" module > that is very different from luazmq. What happens when someone does: > > local zmq = require"zmq" When using luarocks.loader, it should sort it out, but... > 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). > 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. > 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? 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. -- Hisham http://hisham.hm/ ------------------------------------------------------------------------------ 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
