Open splitice opened 8 years ago
@splitice Bytecode is not very portable (for example, LuaJIT 2.0, 2.1 and standard Lua 5.1 all use incompatible bytecode formats). So it does not make sense to do bytecode compilation in the packaging phase for opm (well, it may make sense to your own packaging toolchain since you usually just stick with a particular Lua/LuaJIT version in your own environment).
For opm
, I think it only makes sense to do such bytecode compilation in the installation phase on the user side. But we still need to solve the following problems:
*.luac
to the standard Lua module search paths (package.path
) unless we want to overwrite *.lua
files with their bytecode (we do not want to lose the original source, since the user may need to re-compile it to the a bytecode format (see 1.) or just edit the Lua code to make her own changes either temporarily or permanently.In general, bytecode compilation adds significant complexity and potential problems to the mix. That's why I won't add it any time soon. But it's good that we start talking about any viable solutions to it right now :)
I 100% agree, its an installation step for us. I probably didn't make it very clear.
The main reasoning behind bytecode compilation for us is to accelerate webserver startup & reload.
For us, its just an ansible script with options (lua_deploy_bytecode: True). But I imagine perhaps something like:
opm get --bytecode splitice/resty-awesomeness
The only thing then required is one final step to bytecode compile.
If its an optional flag, perhaps it becomes the users responsibility to worry about platform upgrades?
@splitice Generate the byte code files as *.lua
or *.luac
? You didn't address the 2 problems stated in my previous comment, BTW.
More information.
Our structure is something like this:
packages/source/blah/lib/namespace/file.lua -> lib/namespace/file.luac
lib/ has all packages munged into one structure.
At one point lib was *.lua's maintained by symlinks. Now with bytecode in use, no symlinks.
@splitice Seems like it is not worth adding into opm
. It could be a separate tool that traverses the directory tree and compiles all the *.lua
to *.luac
, including Lua libraries already installed (like those shipped with OpenResty by default).
@splitice Or maybe we could add a bytecode option to OpenResty's build system and OpenResty installs all its standard Lua modules as *.luac
by default. The opm
tool can honor that setting and always installs *.luac
automatically. And OpenResty also always uses *.luac
in its default package search paths.
@splitice The LuaJIT bytecode mode can be an attribute of the user's OpenResty installation, which looks like the cleanest way.
I agree with the last two.
FYI its probably only a small addition either way, just seems like something useful.
@splitice Yes, the implementation won't be difficult at all. Just a design issue. Pull requests welcome :)
Hehe, I think I've heard that before.
Looks good, I'd love our package management processes to get more mature. Many moons ago we developed a basic packaging system for use internally. Nothing at even this level, just something basic which we could use with ansible to version and deploy our code.
One thing we did is integrate bytecode compilation into our process. Effectively the way we did it was with a package step, that similarly to this produces compressed tar balls. Then on the relevant server an installation utility which extracts the code into a directory, then compiles each file, putting the output into a merged directory.
Any thoughts on this?