luaenv (Work in Progress)

Frank Mitchell

Posted: 2023-07-12
Last Modified: 2023-07-13
Word Count: 270
Tags: lua programming

Table of Contents

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 change package.path and 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 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 of rbenv 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 for lua, luac, luarocks, and luarocks-admin, although conceivably a Lua Rock could include an executable script.