On Thu, Oct 21, 2010 at 7:12 AM, steve donovan <[email protected]> wrote: > The solution is mostly on the LfW side (i.e. Ryan and I) but perhaps > this provides some ammunition for the concept of 'virtual' packages > which exist to inform LR that a particular package is already > installed and available, but 'hands off'. (A Debian candidate would be > LuaGnome.) > > It's basically a kind of rockspec which does not deploy to the main > Lua (c)path and is effectively a no-op that exists to fulfill certain > contractual obligations ;) Then on LfW we can pre-populate the rocks > tree and needless downloads and difficulties will not have to happen. > In this case, it is a hole I can escape by writing some scripts that > manipulate the manifest directly, but I hope the general point is > clear.
LfW-friendliness was one of the goals for LR2. With LR2, my plan was to make LR able to manage LfW modules "for real", if LfW shipped a proper manifest file, even if the modules themselves were not compiled using LR. That would allow LfW to have a rocks repo to provide module upgrades, for instance, so that users could use 'luarocks install' to upgrade modules instead of reinstalling LfW. At this point, however, LR2 is hardcoded to Unix-centric deploy subdirs (e.g. share/lua/5.1) while LfW, I believe, is using something different. We could try to harmonize this in a future version so that LfW shipped its modules as a "pre-populated LR tree". Unless you really don't want to mix LR-installed and LfW-installed modules, of course. -- Hisham _______________________________________________ Luarocks-developers mailing list [email protected] http://lists.luaforge.net/cgi-bin/mailman/listinfo/luarocks-developers
