Port this module to Lua 5.2

[teward]

This is marked "high priority" because this impacts the nginx package in Ubuntu.

In order to get nginx into Ubuntu main, the Lua module will need to be updated to work with Lua 5.2. The current 5.1 dependency blocks the package from being acceptable for the process of getting some part of nginx into main.

Unless this module gets ported to 5.2, and relatively soon, the module will have to be dropped in Ubuntu. It will still exist in the Debian-based nginx packages in the PPAs, but it will not be in the Ubuntu nginx packages unless this gets updated for 5.2.

[agentzh]

@teward Why not make the package link with LuaJIT 2 instead of the standard Lua interpreter?

[teward]

I didn't create the dependencies for the package in Ubuntu, those came from Debian. However, as far as I can tell, the version of the module in the Debian-based packages is using the standard Lua interpreter. Unless you care to elaborate on how to make a Debian package build rely on something other than the standard lua5.1-dev libraries.

[agentzh]

@teward No, I know very little about Debian packaging. I'll try adding Lua 5.2 support to ngx_lua today anyway.

[teward]

There's no need to do it today, but maybe within the next several days or a week is fine, there's no immediate rush to get this module ported to 5.2, but we do want to see nginx enter main for Ubuntu 14.04 (the 5-year-supported LTS)

[bakins]

@agentzh Just my opinion, but I really don't care about getting an "official package" in Ubuntu. Five years is a long time and generally most issues are fixed by patches and/or new releases and rapid releases and LTS generally do not go together. at $DAYJOB, we always build our own packages.
Same thing for nginx.com, they want you to run their packages, not the Ubuntu ones.

[teward]

@bakins this is why i maintain the ubuntu PPAs for nginx separately, they're updated because Debian's updated, and I"m usually on top of that. They always get the latest version from Debian unstable.

Nginx upstream wants to see Ubuntu have nginx in main too, I can say that for certain. So does a large portion of the community. That's really why i'm pushing this issue, for the package to get into main this is a prerequisite set by the MIR people :/

[agentzh]

@bakins Yeah sure. We always build our own binary packages for production use too. I just think that it might have a chance to help more people get their feet wet with the ngx_lua module :) The more, the merrier ;)

[bakins]

Just speaking from my experience in other open source projects that have openly request to not be packaged by OS's. I don't care that much either way as I'll continue to build my own.

[teward]

@agentzh actually, I know that quite a few people in Debian and Ubuntu rely on the Lua module already, and they don't want the module dropped to facilitate Main inclusion (which means that nginx can end up on the server image potentially!), but the issue is that Lua 5.2 isn't supported yet here.

Ultimately, though, this is what's gonna happen: Some package will be in Ubuntu 14.04 LTS in Main (Lua module probably won't end up in main, but they won't support the main inclusion until we get this Lua 5.1 / 5.2 thing fixed :/). Later versions of nginx might not end up in the LTS, but will be available by an "nginx team ppa" which I maintain, and that will have latest Stable and Mainline builds. Those PPA builds will have the Lua module anyways, so meh. :/

[agentzh]

@teward Lua 5.2 is incompatible with Lua 5.1 on both the C API land and the Lua land (including various language semantics). If as you said there are quite a few people already using ngx_lua + lua 5.1, then linking against Lua 5.2 will probably break these people's existing Lua code. Lua 5.2 is essentially an incompatible different language.

I've just had a closer look at Lua 5.2 and it seems that it requires nontrivial architectural changes in ngx_lua's basic infrastructure. The most troublesome thing is the quite different "environments" model in Lua 5.2. At this point, I'd hold back adding support for Lua 5.2 to ngx_lua. Also, I don't want to create confusions and incompatibilities on the Lua land for apps running atop ngx_lua (as well as all the existing lua-resty-* libraries written in the Lua 5.1 language).

I'm afraid it is better to stick with one Lua language in ngx_lua. Chasing the Lua language's version number has not many practical technical merits (if there are some political merits).

Please try persuading the packagers to either statically link against the standard lua 5.1.5 interpreter or just link against LuaJIT 2 (like 2.0.2). That is the best option here.

[teward]

@agentzh that's unfortunate, but not unexpected.

Unfortunately, I'm not sure how the module is built before it gets compiled into the nginx binary in the package building process. It may just be as simple as having LuaJIT 2 installed and loaded as a build dependency, or as other methods, I'd have to do some testing or have the other Ubuntu dev helping me on this test it. Thanks for your comments, though, on this, I'll forward this to Debian as well.

[mathieujobin]

What happened with this ? are we still lock with 5.1 ?
What about 5.3 ?

thanks

[teward]

I don't think the state on this has changed...

[mathieujobin]

thanks for your answer, so 5.1 it is.

I quickly baked a few bash functions to easily switch lua version on archlinux

in case anyone is interested

https://github.com/mathieujobin/lua_version_manager

[bungle]

One of the reasons, as I see it, is that this module supports both LuaJIT 2.1 and PUC-Lua 5.1. And LuaJIT is stuck with Lua 5.1. Making PUC-Lua support for say 5.3 and LuaJIT support for 2.1, you are dividing the community that writes plain Lua modules for this platform. 5.1 and 2.1 are quite compatible with each other, so that does not create a huge amounts of incompatibilities. LuaJIT FFI on the otherhand doesn't work with PUC-Lua, of course. It seems that more effort is put on LuaJIT side, and many of the new features gets implemented with FFI interface. Future tells how PUC-Lua and LuaJIT lives together in this module.