On Fri, Feb 15, 2013 at 11:30 AM, Reuben Thomas <[email protected]> wrote: > When I use "require 'luarocks.loader'" in my ~/.luarc (loaded by > LUA_INIT), I find that it changes package.path and package.cpath by > prepending the relevant library directories, e.g. lib_dir. This causes > problems with test suites which want to test a just-built version of a > module, and prepend the build directory to path/cpath, only to find > that it has been overridden in favour of installed modules by > luarocks. > > Since according to the luarocks documentation, you should in any case > change your default LUA_PATH/LUA_CPATH to point to the directories in > which LuaRocks installs modules (if necessary), should LuaRocks really > be changing the paths itself? Just from a tidyness point of view, this > means that the paths LuaRocks uses are duplicated in my > package.{c,}path. > > Note that I do want to be able to use LuaRocks (including, > potentially, multiple version support, hence luarocks.loader) when > building and testing programs, so simply omitting LuaRocks causes > another problem.
I've been thinking about this and it's a little tricky. The documentation recommends changing LUA_PATH/LUA_CPATH so you can find Lua modules installed by LR without needing the loader. When using the loader, I think it's a nicer experience if luarocks.loader can find the rocks_trees by itself without having this configuration replicated in the user's LUA_(C)PATH (remember the rocks_trees path may not be the same as the path where luarocks.loader is installed). But I see your issue. What's happening is that luarocks.loader uses luarocks.cfg and that reconfigures package.(c)path permanently, and yeah, it would be cleaner if all that luarocks.loader did was to add its own loader and not affect the other loaders in any other way. Perhaps luarocks.loader should only temporarily edit the package.(c)path inside the call_other_loaders function? Also, is the fact that luarocks.loader inserts itself as the first loader problematic in your case? -- Hisham http://hisham.hm/ ------------------------------------------------------------------------------ The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials, tech docs, whitepapers, evaluation guides, and opinion stories. Check out the most recent posts - join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Luarocks-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/luarocks-developers
