 |
lua-l archive |
|
|
||
|
Hi Ryan,
To pick on one of the concrete examples you provided...
On Sun, 24 Apr 2022 at 18:52, Ryan S <pyryanggg@gmail.com> wrote:
> I've personally criticized some major breaking changes in the ABI, like the removal of luaL_register. I did not directly ask about this, but I found an old mailing list post detailing that this change was made to discourage people from exporting their module into the global environment. If this is true, I find this one example of a significantly breaking change (making most C libraries incompatible with Lua 5.1+) to simply reflect a (albeit healthy) coding practice. Instead of this, documentation could've been improved to passively coerce C module authors and it'd create a similar benefit without breaking compatibility.
The old behaviour of luaL_register() was very problematic, because it
always inserted the module table into the default global environment,
bypassing any attempts at sandboxing. In Prosody this caused us (and
occasionally still does) many issues, as we prevent plugins from
injecting stuff into Prosody's global environment by default. I agree
the API change has been an annoying transition, but it's a
straightforward change, easily backwards-compatible with 5.1 and it
solves real issues.
> I cannot use the LuaSec, LuaSocket, or lua-cjson modules largely because of this change. And these are massively popular modules.
I don't understand why you can't use these modules? All of them are
compatible with 5.1, 5.2, 5.3 and 5.4. The ABI changes only mean that
you cannot compile the library once and use the produced binary with
any Lua version. However you can compile it for each version
individually, and load the correct one at runtime based on the current
Lua version (e.g. via LUA_CPATH/package.cpath).
> In my own experience, there's been many times I need to read JSON, make a network request, call FFI functions, and furthermore. All of these operations have libraries upon libraries in C to provide this for me, but none work because an ABI function was renamed, slightly modified, or in justifiable cases overhauled. So I quite literally abandoned Lua for these projects because I couldn't be tasked at the time with hacking these modules together or writing my own.
It sounds like you are trying to load binaries compiled for one Lua
version, inside a different Lua version. Why can't you just use
binaries built for the Lua version you are running?
Regards,
Matthew