scoder
Unable to use external lua libraries with lupa-1.5 wheels
My project currently depends on some external lua libraries that I am installing with luarocks. However, since lupa-1.5 now provides wheels on pypi built with the bundled lua-5.3 code I am unable to install external libraries (since the lua runtime is static linked into the lupa library)
Is there some way around this or do I have to somehow avoid using the lupa wheel? As far as I'm aware there's no way to specify wheel vs source build in a requirements.txt so this new duality of bundled vs system lua makes using lupa in a project with non-trivial dependencies much more complex.
The wheels are intentionally built statically with Lua so that users can just pip install lupa, and especially use Lupa as a dependency for other packages, without all that hassle of making sure that things are properly set up for a local build, and then wait for that, see it fail, and try again.
What do you need exactly in order to have Lupa support your external packages?
You might need pip install lupa --no-use-wheel so that while building it will find system lua library
@TitanSnow yes, that would solve my problem, but I can't specify that in a requirements.txt so I will have to adjust my build process to install lupa manually first or something.
@scoder In order to build external lua libraries (with luarocks for example) there needs to be a lua shared library and development headers to compile/link against. I don't think this is resolvable if you static link the lua runtime with lupa at build time.
@TitanSnow actually... ignore the above. I can use pip install -r requirements.txt --no-binary lupa
there needs to be a lua shared library
Wouldn't the header files be enough? It shouldn't normally have to link against the lua library, because that is provided (and already loaded) by Lupa.
I would consider a pull request that makes Lupa ship the header files of the Lua version that it was built with or against, and give it a function lupa.get_includes() that returns the (list of) directories needed for the build.
That being said, I'd also be ok with switching to a dynamic build and shipping liblua, if that's what it takes. Pull requests that work on all major platforms will be considered.
@scoder I think you might be right. Simply shipping the headers may be enough. I think my preference personally will still be to use the system lua though and the --no-binary lupa option to my pip install will be sufficient for that.
@scoder The lua has a config header which might be configured differently on different binary. Such as the bit length of Lua_Integer might be different. How do you deal with this?
lua has a config header which might be configured differently on different binary. How do you deal with this?
Not sure. In any case, include all Lua header files, maybe generate our own Lupa header file, probably remember all macro #defines that were used or set in Lupa at build time. In the worst case, edit the Lua header files at build time, but I'd rather avoid that if possible.
Does that help?
Sorry, I might misunderstand your idea. For exposing header to let other lua extensions to built with, I have no study on it.