1. Does this integrate natively with `package.path` and `package.cpath`?
2. Does it detect non-standard, popular installations like through brew(1)?
3. Can you install by GitHub `:user/:repository`?
Also, neat project! Nice work.
2. It defaults to using pkg-config to detect Lua installations and will fall back to installing Lua via the `lua_src` and `luajit_src` crates if it can't find them. We may eventually add support for other tools like vcpkg.
3. Not yet. It's on our roadmap to add support for that to our lux.toml/dependencies spec, but we probably won't allow rockspecs with that to be published to luarocks.org, because we don't want to be the reason people publish packages that can't be built by luarocks.
Thanks :)
I have a strong opinion on this, as a Lua developer with some experience shipping Lua code.
Good third-party package management for Lua should function independently from the system-provided Lua installations.
It’s all too easy for newcomers to the Lua app-development world to tie themselves into some “auto-detected Lua” path that is, frankly, bonkers. It makes things hard to ship.
If you’re going to write a Lua app, and want to manage your Lua dependencies - use ‘luarocks —local’ and leave system-provided resources out of the picture.
Bundle Lua up front.
This is true of python, also: if you’re going to try to build an app that uses either Lua/python, one must take responsibility for building and bundling locally, and not using system-provided lua/python bindings.
Sure, use “brew —-prefix lua” to get things started, if that has to be a thing. Use pkg-config too, to build the “System/Package-Manager provided” lists.
One of the best practices for luarocks is to know and use the —-local flag with gusto and bravado, and include its artifacts in a larger app build/bundling target. This can be done in a cross-platform manner for all of the major platforms. Having a build target with a successful ‘luarocks —local’, for a locally built Lua and dependencies, does indeed rock. You can put everything in a .local/lua … and treat it just like any other linkable object resource.
If there is one solid rule for effective Lua development, it is: leave the system Lua’s alone, and build your own .local/lua tree, properly.
If you can’t do that, you’ll be missing out on the grand prize: being able to ship Lua with certainty that your Lua bundle will work, regardless of whats onboard the users’ setup … which is, after all, kind of a holy grail of the language, and therefore also a priority of its package management tools.
Another “Lua dev maxim” is, there are many Lua’s. There are reasons to use Lua 5.1 in a project - and reasons to use 5.4 and LuaJIT, too. Switching Lua’s is why I luaenv, but also, you can bootstrap a fresh Lua with CMake real fast, either as a project tool/binary, or directly to the VM abstractions, integrated into your app. A great Lua project has Lua 5.4 in the project, and both developer and end-user host binaries which include a Lua 5.4 environment, sandboxed, built from exactly the same sources. Bonus points for the Desktop/Mobile bridge getting crossed ..
So, depending on a system Lua, is repeating the same mistake prior lua package managers made, maybe. I have reached nirvana with luaenv+luarocks+cmake, personally.
I’m not suggesting lux not try to be self-aware on the basis of finding system standard tooling and libraries for its purposes, but that to be better than luarocks, lux will have to be able to handle —-local builds just as well ..
Luarocks is not just about being a ‘pip for Lua’, its also about having everything relatively tidy to support a fully local build and packaging target. With luarocks you can not use the system Lua, entirely - and that is a pretty significant use-case for luarocks, its utility in the packaging steps ..
I've got some libraries that support five or six different versions of Lua. Building packages for all of them basically means throwing luarocks out the window, because linking to multiple Lua runtimes ti=o luarocks does all kinds of truly heinous things.
You can end up with the library and headers linked from different runtimes, simply because it isn't following what the local system says is available.