LuaRocks 3 compatibility

s-ol commented 4 years ago

Hey, I am currently in need of a way of bundling up a bunch of Lua and binary rock-dependencies together with some Lua code and create a native-ish install experience. luapak seems perfect, but has some trouble cooperating with luarocks 3:

/usr/bin/lua5.3: /usr/share/lua/5.3/luapak/luarocks/cfg_extra.lua:1: module 'luarocks.cfg' not found:No LuaRocks module found for luarocks.cfg
    no field package.preload['luarocks.cfg']
    no file ...

I see that you wrote this quite a while ago and I assume are not interested in working on this yourself currently. I am happy to take a look myself, I just wanted to ask if there is any advice you can give me before I try to find my own way into your source and the new luarocks? Or is there something bigger about luarocks3 that makes luapak not viable to be ported?

4mig4 commented 4 years ago

That would really be welcomed

jirutka commented 4 years ago

Implementation of Luarocks 2 is quite messy and not well extensible, so it required a lot of ugly hacks to make it build static libraries and cooperate with luapak. This should be theoretically better in Luarocks 3, but I didn’t have time nor motivation to look into it.

Anyway, PRs are definitely welcome!

Sledmine commented 3 years ago

I'm also really interested on this, if there is already something going about this I can help for sure

hishamhm commented 3 years ago

@jirutka I believe the only differences in the rockspec format 3.0 that are relevant to luapak are:

dependency names can take the form user/module, which means they are to be downloaded from the user manifest, not the root one
build_dependencies table, which works like the dependencies table, needs to be processed as well (but their contents shouldn't be included in the packed output)
build.type is now optional and defaults to builtin

My guess is that it's probably easier to work the above into your current codebase than to resync the forked code.

Frityet commented 1 year ago

Been working on this cause I really want to use this project myself on newer luarocks versions. I would really appreciate some help as I am not too familiar with the luarocks API

alerque commented 7 months ago

@Friyet did you make any progress on this? I'm looking to perhaps further efforts along these lines a bit myself and am currently looking into whether rehashing luapak is the right move or if working with the stuff in upstream luarocks directly will get me where I want to be with less work. If there is other work out there to build on I'd like to know about it.

jirutka commented 7 months ago

My guess is that it's probably easier to work the above into your current codebase than to resync the forked code.

Luapak is not a fork of LuaRocks; it uses LuaRocks as a dependency. All the code directly interacting with LuaRocks is located in the luapak/luarocks directory – it’s a facade (and kinda anti-corruption layer) for the rest of the Luapak modules. However, LuaRocks 2 didn’t have a sufficient API for this, so it’s hack-ish.

It should be relatively easy to update Luapak. Most of the code is decoupled from LuaRocks. The hard part is to dig deep into the LuaRocks code base, which has been rewritten in v3, and figure out how to rewire it.

jirutka commented 7 months ago

if working with the stuff in upstream luarocks directly will get me where I want to be with less work.

When you look at the readme, only the first step (corresponding to the build-rock command) is in the (current) scope of LuaRocks. It would be cleaner and probably easier to add support for building static libraries into LuaRocks rather than hacking it from outside, and it would simplify Luapak considerably.

alerque commented 7 months ago

For my project (A Rust app with built in Lua VM and embedded LuaRocks) only the build-rock part matters to me. The rest of what luapak does is already covered by the Rust build system that bundles and embeds everything anyway. The only issue I have is the embedded C modules are still dynamically linked to system libraries. Amazingly they work like that but are dependent on the same version of system libraries (like ICU for example). That's what I'm trying to fix.

I'll probably be looking more at the LuaRocks side of things for now but using some of this as a reference. If that benefits Luapak in the end that would be great.

Frityet commented 7 months ago

@Friyet did you make any progress on this? I'm looking to perhaps further efforts along these lines a bit myself and am currently looking into whether rehashing luapak is the right move or if working with the stuff in upstream luarocks directly will get me where I want to be with less work. If there is other work out there to build on I'd like to know about it.

I did, and could not get anywhere no matter how hard i tried, it was a huge mess

jirutka / luapak

LuaRocks 3 compatibility #8