Upcoming changes to luapower
Just wanted to lay out the changes that will happen to luapower in the next few days. These will probably make things confusing for a while until the documentation will be in sync with those changes. Feel free to ask questions here if you get stuck.
The biggest change is the separation of the package manager as a standalone program. It is now called "multigit" and it's developed here:
Documentation on that will be the first thing to add after I finish testing it on all platforms (if you used luapower-git before you probably know where this is going).
The reason for the change is that the package manager had nothing to do with Lua from the beginning. It's just a git wrapper for working with overlaid repositories and developing it and documenting it separately should hopefully make that clearer, and make it useful for other people and projects too. It's such basic functionality that I think it should be built into git really, so no point tying it to luapower.
This brings in some benefits: now the list of luapower repositories is itself just a separate repository, which is here:
So now that the package collection itself is a package, you can use multigit to bring together different package collections from different sources into the same luapower installation and then use
mgit clone-allto clone all the packages from those collections.
So now luapower is:
- a set of arbitrary rules of how packages must be laid out so that when cloned together with multigit they will form a runnable luajit installation on-the-spot.
- the current module collection which follows these rules
- a Lua module called "luapower" which reflects on these rules to extract metadata about dependencies, etc. (the website sits on it)
- multigit, which is used as the "transport" and "change management" layer -- git does these best and there's no need to have anything Lua-specific here.
back to work now :)
Update: documentation for multigit is now up, check it out:
Sorry for pushing this thread, but I had a suggestion which would be quite handy if it was implemented on mgit.
mgit compiling Lua code into a dynamic libraries.
I believe there are several ways to implement this; pushing the Lua functions being exposed into some library, expose them as FFI callbacks, looking up for the functions on the global environment, etc. And having a automatic wrapper which tell what functions are allowed to be exported.
The result may come into a slow implementation but at least there's the possibility to rely on being able to actually develop alternative dynamic libraries for software that doesn't support Lua or LuaJIT, which is much more simple than compiling code on some older low level programming languages (C/C++).