luarocks VS packspec

LUA_INCDIR is not listed on either https://github.com/luarocks/luarocks/wiki/Installation-instructions-for-Unix or https://github.com/luarocks/luarocks/wiki/Installation-instructions-for-Unix but luarocks complains that it's not set. What does it do?

Luarocks packages (or "rocks") provide a rockspec, which luarocks uses to build the package and resolve dependencies.

The luarocks.loader module is provided by Luarocks and basically replace the standard require function by a version that handles Rocks installed with Luarocks (https://github.com/luarocks/luarocks/wiki/Using-LuaRocks#multiple-versions-using-the-luarocks-package-loader and https://github.com/luarocks/luarocks/blob/master/src/luarocks/loader.lua). Note that this is safer than your implementation since it "knows" the running Lua version and the corresponding Luarocks installed files. So it will automatically load modules at the correct version / path (without additional set_path and hard coded string).

I would reccomend you use luarocks for the project. It’s the “standard” package manager for lua, and supports building the C parts (using autotools). It also manages the dependencies for you!

What kinds of trouble? It looks like it's under active development https://github.com/luarocks/luarocks/commits/master ...have your troubles with it been specific enough things that you could post them in the issue queue?

what luarocks version are you running? If it is the one from luaForWindows, then I recommend upgrading it (https://github.com/luarocks/luarocks/wiki/Download). Solved my include problems but requires a bit of configration

It looks like there's a WIP package specification that might also support source = luarocks://.

I was hoping you would clarify exactly what you're proposing so I could forward the appropriate link, otherwise I'm just guess based off a vague (but long) post. Based on other replies in this reddit post, I'm not the only one confused by your ambiguous and likely incorrect terminology. It sounds like you're looking for a specification, which exists https://github.com/nvim-lua/nvim-package-specification, it just isn't well adopted. There's also countless Github issues and discussions about this on IRC which you could find by a simple Google search. It really just depends on what you're alluding to which is why I linked what an API was so you could be more specific. If you're looking for the plugin managers API (notice the qualifier) to be consistent, then that's not a good idea since the API of the plugin manager is what differentiates them, it's like saying all programming languages should be the same, the only thing different should be the backend (e.g. gcc vs llvm). The consistency should be at a different layer (thus the plugin spec).

packspec, a package specification for neovim to address the dependency issue

There is an issue for it: https://github.com/nvim-lua/nvim-package-specification/issues/23