Currently, --lua-path entries must be either a path pattern with an absolute path prefix (/usr/local/share/pico8/?.lua) or a path pattern forward-relative to the file calling require() (?/?.lua). This is sufficient for users that always put their libs in a specific place or projects where all source files are in the same dir. But this puts a burden on library authors to educate users on setting the --lua-path, and doesn't make it easy to provide a portable command invocation in library documentation.
My own intuition would have been to document an invocation like this:
where mydemo.lua might contain require('somelib/foo') and somelib/foo.lua is in the library's top-level alongside demos/. The ./?.lua does not work as expected. If I replace it with $PWD/?.lua it works as intended, but this is more shell-specific and less portable.
I think the right solution is to shell-expand Lua path entries only when given with --lua-path. /x/y/z/? and a/b/? behave as before (absolute FS path and require-relative, respectively). ./a/b/? would expand to an absolute FS path relative to the current working directory (equivalent to $PWD/a/b/? as expanded by the shell itself). I don't see a reason not to support ../a/b/? or ~/a/b/? (user home dir expansion) in this way when provided directly on the command line.
It's worth experimenting with the official Lua interpreter to see what it supports, and try to match.
Currently,
--lua-pathentries must be either a path pattern with an absolute path prefix (/usr/local/share/pico8/?.lua) or a path pattern forward-relative to the file calling require() (?/?.lua). This is sufficient for users that always put their libs in a specific place or projects where all source files are in the same dir. But this puts a burden on library authors to educate users on setting the --lua-path, and doesn't make it easy to provide a portable command invocation in library documentation.My own intuition would have been to document an invocation like this:
p8tool build --lua-path "?;?.lua;./?.lua" --lua demos/mydemo.lua mydemo.p8where mydemo.lua might contain
require('somelib/foo')andsomelib/foo.luais in the library's top-level alongsidedemos/. The./?.luadoes not work as expected. If I replace it with$PWD/?.luait works as intended, but this is more shell-specific and less portable.I think the right solution is to shell-expand Lua path entries only when given with
--lua-path./x/y/z/?anda/b/?behave as before (absolute FS path and require-relative, respectively)../a/b/?would expand to an absolute FS path relative to the current working directory (equivalent to$PWD/a/b/?as expanded by the shell itself). I don't see a reason not to support../a/b/?or~/a/b/?(user home dir expansion) in this way when provided directly on the command line.It's worth experimenting with the official Lua interpreter to see what it supports, and try to match.