You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Provide all of Lua 5.3/5.4 and LuaJIT in a single package #196
Hmm. Given how small the Lua implementations are, I think it would be cool if the Lupa wheels shipped just all available options, say, Lua 5.3/4 and LuaJIT, as a Package. Then importing "lupa" would just give you the latest Lua 5.x, as it's the case now, and importing "lupa.luajit2" would give you the same API but built with LuaJIT 2.x. This could all come from the current module implementation with a more elaborate build setup.
PR very welcome.
Reacted by Roman Alexander, Tatu Ylonen and Deficuet
lupa - from .lua54 import * (i.e. delegating to latest Lua module, as it already does now)
lupa.lua53 - Lua 5.3.x
lupa.lua54 - Lua 5.4.x
lupa.luajit20 - LuaJIT 2.0.x
lupa.luajit21 - LuaJIT 2.1.x
Basically, the setup.py script needs to create multiple Extension instances (instead of just one) for the same lupa/_lupa.pyx file but with different extension module names.
It would probably also be a good idea to create a separate git submodule under third-party/ for each of the Lua/LuaJIT versions, so that they can be separately pinned and built from there.
I strongly support making lupa available with different Lua versions! I'm using lupa extensively for Wiktionary extraction (https://github.com/tatuylonen/wiktextract, or actually its subpackage https://github.com/tatuylonen/wikitextprocessor). Wiktionary uses Lua 5.2, and I have no way of upgrading the Wiktionary modules to Lua 5.3 or 5.4. I've coped with Lua 5.3 by patching the Lua source code using essentially a few dozen regexp-replaces, but it is a horrible kludge. Now with Lua 5.4, it has again changed in several incompatible ways, including changes in supported format strings and apparently the operation of metatables has also changed in subtle ways. It's coming to a point where I'll have to start building and releasing my own version of lupa compiled for an older version unless there is support for either selecting the version to use when creating a Lua context or installing a separate package. The proposed way of, e.g., lupa.lua53 works, but I would very much prefer using Lua 5.2. The English Wiktionary alone contains 322,000 lines of Lua 5.2 code, and when counting the other language editions and Wikipedia, it is probably millions of lines of Lua 5.2 code in Mediawiki projects alone. It is not going to get upgraded from Lua 5.2 any time soon, I think.
I came to this repository with the intention of submitting an issue to request this feature.
There is currently no build procedure for LuaJIT (although the sources are bundled) and building Lua 5.2.3 also fails.
Help with that is welcome, otherwise I'd just keep it as it is for now.
The PR is mostly working now. I'm not sure about the interface, though. It seems clumsy to write
importlupa.lupa_lua54aslupa
Also, import lupa currently imports the Lua 5.4 version, so import lupa.lupa_lua53 loads both Lua 5.3 and Lua 5.4.
Rather, it would be nice to say
importlupa.lua53aslupa# or ... as lua ?
and have import lupa basically do nothing. But that's backwards incompatible (which would be acceptable for the intended Lupa 2.0 but not great) and also seems a bit less clear – from lupa import lua53 returns the same kind of module as from lupa import lua54, just with a different Lua version. There could still be a submodule (e.g. lupa.lua) that would always refer to the latest (or only) Lua/LuaJIT module.
Activity
scoder commentedon Nov 1, 2021
[-]Windows wheels use Lua 5.3 not LuaJIT[/-][+]Provide all of Lua 5.3/5.4 and LuaJIT in a single package[/+]scoder commentedon Feb 23, 2022
Module names to provide:
lupa-from .lua54 import *(i.e. delegating to latest Lua module, as it already does now)lupa.lua53- Lua 5.3.xlupa.lua54- Lua 5.4.xlupa.luajit20- LuaJIT 2.0.xlupa.luajit21- LuaJIT 2.1.xBasically, the
setup.pyscript needs to create multipleExtensioninstances (instead of just one) for the samelupa/_lupa.pyxfile but with different extension module names.It would probably also be a good idea to create a separate git submodule under
third-party/for each of the Lua/LuaJIT versions, so that they can be separately pinned and built from there.tatuylonen commentedon Mar 4, 2022
I strongly support making lupa available with different Lua versions! I'm using lupa extensively for Wiktionary extraction (https://github.com/tatuylonen/wiktextract, or actually its subpackage https://github.com/tatuylonen/wikitextprocessor). Wiktionary uses Lua 5.2, and I have no way of upgrading the Wiktionary modules to Lua 5.3 or 5.4. I've coped with Lua 5.3 by patching the Lua source code using essentially a few dozen regexp-replaces, but it is a horrible kludge. Now with Lua 5.4, it has again changed in several incompatible ways, including changes in supported format strings and apparently the operation of metatables has also changed in subtle ways. It's coming to a point where I'll have to start building and releasing my own version of lupa compiled for an older version unless there is support for either selecting the version to use when creating a Lua context or installing a separate package. The proposed way of, e.g., lupa.lua53 works, but I would very much prefer using Lua 5.2. The English Wiktionary alone contains 322,000 lines of Lua 5.2 code, and when counting the other language editions and Wikipedia, it is probably millions of lines of Lua 5.2 code in Mediawiki projects alone. It is not going to get upgraded from Lua 5.2 any time soon, I think.
I came to this repository with the intention of submitting an issue to request this feature.
scoder commentedon Mar 6, 2022
See #207
scoder commentedon Mar 6, 2022
There is currently no build procedure for LuaJIT (although the sources are bundled) and building Lua 5.2.3 also fails.
Help with that is welcome, otherwise I'd just keep it as it is for now.
scoder commentedon Mar 9, 2022
I got LuaJIT to build at least on Linux. That way, it can be used with a conditional import and a fallback to normal Lua.
scoder commentedon Mar 9, 2022
The PR is mostly working now. I'm not sure about the interface, though. It seems clumsy to write
Also,
import lupacurrently imports the Lua 5.4 version, soimport lupa.lupa_lua53loads both Lua 5.3 and Lua 5.4.Rather, it would be nice to say
and have
import lupabasically do nothing. But that's backwards incompatible (which would be acceptable for the intended Lupa 2.0 but not great) and also seems a bit less clear –from lupa import lua53returns the same kind of module asfrom lupa import lua54, just with a different Lua version. There could still be a submodule (e.g.lupa.lua) that would always refer to the latest (or only) Lua/LuaJIT module.Comments welcome.
scoder commentedon Mar 10, 2022
The incompatibility can be resolved with PEP 562 (module level
__getattr__), that's done.That makes
from lupa import lua53more appealing now. I changed the module names as well.Ship multiple Lua versions in separate extension modules (GH-207)