Project: LuaRocks per project workflow

LuaRocks per-project workflow

Pain point to fix

• managing multiple rocks trees is complicated
  • LuaRocks is based on a 10+ year old design from when rubygems was the state of the art
  • new users expect a per-project behavior, npm-style
    • LuaRocks has the necessary machinery for that, but it's cumbersome to set it up

Proposed approach

• a git-style .luarocks directory: if .luarocks and lua_modules directories are found in the current directory (or any directories above it), it will become the "project root" directory
• a new command, luarocks init sets up a project:
  • creates a .luarocks directory in the current directory
  • writes a template rockspec file if none exists
    • uses the machinery of luarocks write_rockspec, which does some git-specific detection, so the command should "do the right thing" when executed from inside a git clone
• offer a bullet-proof way to run Lua and LuaRocks using the current project tree
  • Option 1:
    • creating lua and luarocks launcher scripts in the current directory that are hardcoded to use the project tree
  • Option 2:
    • adding a luarocks exec command (in the style of bundle exec which runs a command using LuaRocks's own bundled interpreter and is .luarocks-aware
• luarocks build with no arguments acts like luarocks make
  • luarocks make is then deprecated?
• Current multi-tree support remains available
  • Users who have the existing workflow in place won't need to change
  • ~/.luarocks in the $HOME directory does not qualify as a project directory (if ~/lua_modules doesn't exist) so this won't change the default behavior of luarocks when not using project directories.

Status

• Working branch for luarocks init: https://github.com/luarocks/luarocks/tree/luarocks-init

Open Questions

• With Option 2, how do you use a different Lua interpreter (e.g. to test different Lua versions)

  • luarocks-5.1, luarocks-5.2, luarocks-5.3, luarocks-jit2.1, etc. binaries?

• Where will the Lua modules themselves live? Inside .luarocks (this is compatible with the current ~/.luarocks or in a new lua_modules directory (copying npm)

  • lua_modules has better visibility (and familiarity for those used to npm); users will be able to inspect rocks more easily; .luarocks would be for config files, caches and other "hidden" things
    • inside lua_modules, a regular version rocks tree should exist: e.g. lua_modules/share/lua/5.3/foo.lua