Re: Path change to LUA_CPATH in Lua Binaries

[Hisham <hisham.hm@...>]

On Sat, Aug 23, 2008 at 12:03 PM, RJP Computing <rjpcomputing@gmail.com> wrote:
> On Sat, Aug 23, 2008 at 3:00 AM, David Manura <dm.lua@math2.org> wrote:
>>
>> RJP Computing writes:
>> > The change I am proposing is to add 'clib' to the LUA_CPATH
>> > example LUA_CPATH: ;;?.dll;<lua_dir>\clibs\?.dll;...
>>
>> In general, this may be a good idea.
>>
>> However, in the case of Lua for Windows, if it incorporates LuaRocks, the
>> search
>> paths will be determined by LuaRocks, which redefines the "require"
>> function and
>> imposes it's own "appdir" isolated per-package directory structure[1-2],
>> similar
>> to those seen in OS X and elsewhere[3-4].  This differs from the flat
>> directory
>> structure typical in UNIX, currently used in Lua for Windows, and implied
>> in the
>> above suggestion.

LuaRocks does not impose its structure to apps necessarily; when a
module is not found in the LuaRocks tree it falls back to standard
require(), so modules are searched for in the user's
LUA_PATH/LUA_CPATH.

> What if you didn't use LuaRocks in the exact way that it was intended and
> only used it to get new modules. Specifically, I am saying _not_ to use the
> 'require "luarocks.require"' statement at all. Then use LuaRocks to install
> the modules into a directory that LfW has already setup, to look in for new
> modules. I understand that this takes some functionality away, but I think
> this is about the best way to use LuaRocks in LfW right now.

Do you mean moving modules away from the rocks tree? This might
confuse the system. If the plan is to ship both LuaRocks and non-rocks
modules, my suggestion would be to have a usual flat lib directory
with non-rocks modules, and to ship a rocks tree populated with stub
entries for modules that are already there as non-rocks (so that, for
example, when a user types 'luarocks install shake' it does not
download LuaFileSystem again, assuming it would be one of your
non-rocks modules.)

-- Hisham