Re: Lua plugin manager library

[Hadriel Kaplan <HKaplan@...>]

Thanks for the info Hisham!

Correct me if I'm wrong, but last time I checked LuaRocks did most of its work inside Lua itself, and to grab the rockspec/modules used LuaSockets, right?  I.e., it's essentially a Lua app/modules.

That makes a lot of sense for LuaRocks as a stand-alone app, and certainly makes sense for embedding LuaRocks inside a Lua-based application.  But for embedding in a large C/C++ application, that only happens to use Lua for high-level plugins, I'm not sure it's the right approach for a bunch of reasons.  At least not for the apps in my day job, nor for Wireshark (which is where this question arose from).  It is intriguing though… I'll have to think about it some more.

-hadriel


On Feb 15, 2013, at 2:59 PM, Hisham <h@hisham.hm> wrote:

> On Fri, Feb 15, 2013 at 5:36 PM, Hadriel Kaplan <HKaplan@acmepacket.com> wrote:
>> Howdy,
>> Does anyone know of an open-source library one could use in an application to provide the underlying code
>> for managing Lua scripts used as plugins?  I.e., to let a C/C++ application which uses Lua for "plugins"
>> provide a list, search, and retrieve mechanisms for Lua plugins, from their application-providers site?
>> Something like sparkle/winsparkle but cross-platform, and preferably without a GUI component?
>> I guess basically like LuaRocks, but meant for C/C++ application integration.
> 
> I've worked for a while on making LuaRocks a little more "embeddable"
> so you could use in scenarios like this. This is a feature I've been
> aiming for version 2.1, but I was sidetracked into working on other
> features during the last year.
> 
> The current WIP is in the "context-object" branch:
> 
> https://github.com/keplerproject/luarocks/tree/context-object
> 
> The main drawbacks in the current 2.0 design is that LR uses global
> state (the idea for 2.1 would be to wrap this into a state table, the
> "context object") and that there isn't a well-defined and stable
> public API for programmatic control beyond calling run() on the
> various luarocks.* modules which correspond to the luarocks commands.
> 
> In other words, if you were to use LR 2.0 as an embedded plugin
> manager, you could launch a new lua_State for each operation and then
> load the command's module and call its run() method There's probably
> some initialization done by the luarocks.command_line module that
> would have to be redone as well -- I've already refactored some of
> this in the context-object branch.
> 
> If you're interested in it, cooperation on this front (coding, testing
> and/or feedback) is most welcome.
> 
> -- Hisham
> http://luarocks.org/
>