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
luarocks
script itself. Worse, Lua’s module loader assumes Lua is installed in/usr/local
on Unix systems. Users can override the search path in the standlone interpreter by setting an environment variable, and within the interpreter one can changepackage.path
andpackage.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
lua
at 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.
luaenv
need not support every facility ofrbenv
though. A user default version overriden by an environment variable would suffice. (Directory-specific configuration would be nice to have, though.)luaenv
would also need only a few “shims”, mainly forlua
,luac
,luarocks
, andluarocks-admin
, although conceivably a Lua Rock could include an executable script.