Until I can spec this out fully, I’m just going to quote my original blurb:
Even though Lua was intended as an embedded language, its standalone interpreter makes testing modules much easier. However, testing against multiple versions of Lua isn’t exactly straightforward. luarocks, a module manager similar to Ruby Gems, hard-codes the path to Lua not only in config files but the
luarocksscript itself. Worse, Lua’s module loader assumes Lua is installed in
/usr/localon Unix systems. Users can override the search path in the standlone interpreter by setting an environment variable, and within the interpreter one can change
package.cpath. It might be simpler, though, to change those defaults to the directory in which Lua is installed – found once in luaconfig.h – and then compile the interpreter.
Following in the footsteps of rvm and especially rbenv, this Lua Environment Version Manager thing would let developers install multiple versions of Lua in their home directories, set a default, type
luaat the command line, and it would Just Work. Likewise installed Lua Rocks would Just Work.
A fully functional version would download Lua versions, tweak the default load path, compile Lua, and install it in a version-specific directory. Subcommands would set the default version, list all installed versions, uninstall a version, and so on.
luaenvneed not support every facility of
rbenvthough. A user default version overriden by an environment variable would suffice. (Directory-specific configuration would be nice to have, though.)
luaenvwould also need only a few “shims”, mainly for
luarocks-admin, although conceivably a Lua Rock could include an executable script.