--verbosemight help us figure out what's going on wrong. There might be a bug with dealing with different drive letters, since LuaRocks is mostly tested on Unix (where there are no drive letters) and the Windows CI runs on Appveyor where everything runs off a single drive
--verboseand paste the full output into gist.github.com then send us a link
luarocks configmay also help
luarocks maketo create a binary rock locally, but I'm curious about the same for source rocks
builtinand get the list of files from
build.modules) and SCM-agnostic (can't assume
gitand use it to get the list of files).
luarockstool has gotten better at maintaining multiple lua versions at the same time recently, but when launching
luato run it, everything always boils down to your environment variables
LUA_CPATH_5_3for Lua 5.3 (with unversioned variants
LUA_CPATHas fallbacks), same thing for Lua 5.2, and only the unversioned ones for Lua 5.1
luarocks path --lua-version=5.xoutputs the correct values for the Lua version 5.x you want to use
luarocks pathshould lead you in the right direction!
external_dependenciesentries, where the rockspec author could give customized instructions. A slight complicator of putting something like a
scriptfield there would be the fact that system package managers usually need root privileges, while rocks can be installed locally.
hererocksby the way, I've never seen that. It looks cleaner than the Lua rigging we have for