On Fri, Mar 25, 2011 at 3:15 PM, Peter Drahoš <[email protected]> wrote: > > > On Wed, Mar 23, 2011 at 4:06 AM, Hisham <[email protected]> wrote: >> >> ... >> I don't know exactly what path you have in mind for integrating the >> use of LuaRocks and LuaDist (making the "cmake" mode hook into LuaDist >> when available; making a "luadist" mode so that LR delegates the build >> part to the luadist tool; building .rock files with LD and just >> deploying them with LR; something else entirely). I don't have any >> opinions at this point on what direction would be best. I gave LD a >> spin, took a look at its (nice and lean) architecture, but haven't >> been able to allocate time for closer investigation yet. This should >> change a few weeks from now, but in the mean time I'm happy to assist >> any way I can. > > I integrated it with LuaDist the best way I could at the moment[1] (works on > OSX and Linux). I have the following issues on Windows and Cygwin: > > - luarocks.config has rather limited influence. It does override some of the > defaults in luarocks.cfg but not for all platforms. It does not allow to set > 3rd party utilities such as compression tools, 7zip is hardcoded on windows. > I would expect luarocks.config to to be able to override all defaults and > settings, even compiler commands and flags (I could auto-configure these > from CMake).
The plan is for it to be able to override all defaults/settings needed, so I went adding flags and options in an on-demand basis (instead of making absolutely everything configurable from the start). We can improve on what's necessary. > For example on Cygwin it hardlinks to -llua and ignores LUA_LIB > and LUA_SUFFIX. The Cygwin entry with the pipe is a hack, but it was reported to work so I added it while we didn't have anything better. > - Path handling. One of the reasons I decided to not use LuaRocks before. It > inconsistently uses windows and unix paths, has problems determining what > paths are full paths from relative paths. Additionally it has problems with > path separators. For example on Windows I get: > Failed unpacking rock file: C:\work\Repository/C:\Users\AppData\... Windows support suffers from little testing compared to Unix. Originally I wanted to abstract path handling entirely (that's why there are functions such as dir.path) but at some point it was said that it would be simpler to use forward slashes throughout and just convert them at the very end, etc. The original "bootstrap mode" which doesn't use luafilesystem complicates things as well, since it does bookkeeping of the "current" directory internally. > - Too many dependencies. I get that it tries to rely on whatever is > available to get the job done but in the end it has just too many points of > failure. This also results in rather large package thats hard to maintain, > for example the luadist utility has about quarter of the code size with > heavily documented code. It provides comparable functionality and only uses > unzip and cmake. I want to simplify this as well. Right now I think the major problem is that it tries to use any combination of available tools or modules. I still think that being able to download the LuaRocks .tar.gz and use it on Unix without requiring to build modules is an important feature, though. The direction that seems best for me now is to have two modes of operation, one completely based on 3rd-party tools and one completely based on modules. The first mode could have limited functionality, but it could be able to install modules necessary to switch to the module-based mode. This would reduce the number of moving parts. I understand that LuaDist can do this and will be the preferred mode to do this on Windows (I don't think we'll need to support this bootstrap mode on Windows), but I think on Unix a simple bootstrap without any dependencies that aren't already in a typical Linux system (apart from Lua of course) is important for developer adoption. > I can deal with most of these issues by modifying LuaRocks to fit into > LuaDist but I think it would be better for both projects to converge. I do > not plan to develop the "luadist" install utility further and would like to > concentrate on providing working packages and portability instead. I can see > LuaRocks filling that spot but not in its current state. My recommendations > for the 3.0 release would be: > - Use only Lua dependencies (lfs, luasocket, md5.. ), make 3rd party tools > (svn, git, 7z) entirely optional. The install can be bootstrapped and > auto-configured using LuaDist. That's certainly the case on Windows. On Unix, I'll try to keep the "bootstrap mode" around. > - Do not reinvent the wheel and use 1-2 well tested (preferably portable) > build approaches, eg. builtin, cmake. Support for other approaches should be > discouraged/removed. I'm all for discouraging the hacky Makefiles that were so prevalent in the Lua world and I can see a near future dominated by builtin and cmake, but I'd rather keep the build backend open-ended (possibly through plugins). Who knows what the future will bring? Suddenly some new tool may gain importance along developers (such as when git took the world by storm). I didn't check the numbers but I think most make-based rockspecs are the earliest ones we made from Kepler projects. > - Rewrite path handling entirely. I'm not in love with the current path handling, so if it needs fixing/rewriting then let's do it. > Do not assume components are installed statically As in "don't just call 'tar', let the user override this with possibly a full path to the tool" ? > add prefix capability for all paths used. Not sure what you mean by this, please clarify. > - All defaults should be configurable, not only some aspects as is the case > now. Reiterating, I'm open to make it more configurable to match our actual needs. I just don't want to try to foresee every possible need users may have. Trying not to fall in the same mistake of "too many moving parts" again. > - Reduce code size, remove obsolete functionality, try to consistently > handle most systems with the same approach. I think all changes we're talking about here point in these directions, which is a good thing. > - Provide an API for use from Lua (good for GUIs and Automation) This shouldn't be hard, but IIRC the app keeps some global state that needs to be properly encapsulated. > - Reconsider removing support for "rockspec" installation, instead use > "rock" only packages, the former causes fragmentation and download problems. Using bare rockspecs is popular among developers (myself included). LuaRocks already favors rock files over rockspecs in installation, which covers download problems for repositories we keep (nowadays I consistently upload .src.rock files along with the rockspecs). > Please do not read this as criticism, I really do want LuaRocks to be better > and think these problems need to be addressed. What better time than now ? Constructive criticism/opinions like this are more than welcome! I think the direction of LuaRocks 3 is shaping nicely. -- Hisham _______________________________________________ Luarocks-developers mailing list [email protected] http://lists.luaforge.net/cgi-bin/mailman/listinfo/luarocks-developers
