Instead of completely encapsulating each package in its own directory:
luapower/lib/lib.lua
luapower/lib/stuff.lua
So instead of being able to just cd to luapower and git clone repo, you need to use a silly wrapper script that overlays the repos with each other. All of this presumably because the author wanted to type `require "lib.lua"' instead of `require "lib/lib.lua"'
I like it, I'd like even one step more, of making a ZIP of all of the packages. I never modified in place any Perl or Python module, and I don't expect I'd do it with Lua, so having a small portable file set of just a few self sufficient files I could copy to the another machine is my real wish.
But it's arguably easier to package the other way I described, just stick all of the relevant directories into a zip file, instead of needing to manually pick out the "lib.lua" files from the base directory. Literally the only benefit of this approach is saving a few characters on require statements.
For anyone interested in creating a new language, make your equivalent of `require "lib_directory"' do the equivalent of `require "lib_directory/init.lua"' or `require "libname_directory/libname.lua"' so we don't have this issue.
Do you actually do that manually? Why isn't there a script for that? It should be a part of the automated process. Much better doing it once as an automatic step than writing everywhere in your sources:
somethingbig/somethingbig
every time you use somethingbig. And that step should also zip the modules, I believe.
The behavior of require, as I'd like it:
require X first looks in the directory X, for module X. If there is no such, it opens modules.zip and reads module X from there. If internally in the ZIP there were a subdir for every module, I don't care, as long as I don't have to type that fact every time.
modules.zip would be constructed automatically. Whoever wants to tweak some specific module can unpack it in the separate directory.
Having reread the Lua manual, `require "lib"' can easily be made to execute `require "luapower/lib/lib.lua"' by adding "luapower/?/?.lua" to LUA_PATH. This is the way the standard /usr/local/lua libraries are require'd. Now I cannot think of a single explanation for why luapower works the way it does.
> To determine its path, require first checks the global variable LUA_PATH. If the value of LUA_PATH is a string, that string is the path. Otherwise, require checks the environment variable LUA_PATH.
Even if you needed to modify an environment variable, I still think that would be preferable to creating yet another package manager and fracturing the Lua userbase further.
As a user, I want to "just use it" and the binary to "know" where the stuff of the module is without me having to hold its hand. Specifically, I don't want to know about LUA_PATH unless to use it to point to the single dir where I put my own modules.
Your concern doesn't make any sense. Any package manager has to modify LUA_PATH in order for require to work with it in that way (unless it installs libs in /usr/local/lua, which requires admin privileges and isn't portable to Windows). luapower surely does this already, adding "luapower/?/?.lua" to the path instead of "luapower/?.lua" is a one-line difference. It's completely tangential to the criticism I gave.
Thanks! If it would allow that the modules locally exist inside of a single ZIP file instead of the single directory, it would be almost exactly what I want.
Then the "getting started" would be
"download luajit
choose/download wanted packages along with their listed dependencies
unzip all over the same directory
(optional) rebuild binaries
(optional) zip all modules to modules.zip. <== new
run a demo: luajit ..._demo.lua
This will give you an instantly portable luajit distro with only a few small files!"
