lua_package_path and lua_package_cpath at server level

[openresty]

lua_package_path and lua_package_cpath at server level

[agentzh]

Yeah, it'll be required to set cpath/path on per-request basis. But there's more complications here. Because the Lua vm is shared per worker process and users' Lua modules are cached once they're loaded, it'll not be possible to load multiple versions of the same module in different virtual servers and it'll be confusing to the end users if they're trying to do so via different cpath/path settings.

I'm not sure I'd agree with the 'confusing' part. It's common with Apache, Litespeed etc to have a per-server include path for PHP. I don't see any difference between that and having a potentially different path/cpath for lua.

However, if module-loading doesn't work like includes do in PHP etc, and if the module loading isn't going to work correctly on a per-server basis, then I'll drop it for now.

I might look into a patch for Lua that would allow for the module loading to be more like PHP includes at some point, though.

[agentzh]

I didn't mean having separate search paths for each virtual server is confusing; what I meant is that due to the current implementation, it's hard to do module separation on a per virtual server basis.

I thought more about it last night and now I believe the right approach to this is to create individual lua vms for each virtual server, or it'll be impossible to load different versions of a lua module into different nginx virtual servers. Will you work on that? ;)

I think a slightly better approach would be to create new per-server VMs only when required. This would be in at least the following situations:

• a path/cpath is specified in the server block that is different to the one in the http block
• a path/cpath at the http level contains a variable (I've not checked if the path can now or not)

If the server-level VM were to use the same path and cpath as the http block, there's no need to create a new VM.

This feature isn't a priority for me right now, as I'm only going to be using ngx_lua for one site at a time right now, and I'm busy trying to get Tagmata up. I'll add it to my TODO list, though, and will let you know if/when I start working on it, though. (Sorry I can't be more committal.)

[agentzh]

I'm just wondering if this is a premature optimization? ;)

Thank you very much for your contribution :)

Well, it depends on how much RAM the Lua modules take up. I guess they're probably not going to take up much room, but if you have a lot of servers, they might add up. Doing a check on if the VM can be reused or not is a pretty minor bit of coding, so it might as well be added in.

Also, I think keeping variables out of the path/cpath is probably best also (as indeed you have done), so the second bullet above is unnecessary.

[agentzh]

I'm fine with your suggestions here over all :)