Motivation / Problem Statement

I wanted to drill down into the problems with the current Luarocks installation process. There's an excellent corpus of issues on the repo proper:

I've mostly looked at Windows issues because that's where I would expect that the developer experience is the worst. Based on the number of labelled issues, MinGW seems to improve the experience. I wouldn't be surprised if a properly configured Cygwin environment also made things simpler. Although this may be selection bias as the users capable of installing and configuring Cygwin are going to be less likely to encounter issues setting up Luarocks generally.

More work should be done to categorize issues from more than just this single source but from this cursory overview I can begin to identify a few distinct problem areas.

Compiler infrastructure and environment on Windows. This is probably not solvable. Rust does a decent job of it but they own the whole ecosystem and can put guardrails in place. Maybe improvable in concert with package structure and validation but the flexibility that rocks offer with regards to packaging means that this almost certainly can't be made to work for all users.
Package validation - particularly cross-platform. This segues into but is distinct from compiler infrastructure. There are some issues about invalid rocks being published. There really isn't a reason to ever allow that to happen unless the packaging allows so much flexibility that it can't be validated (which is where the compiler infrastructure ties back in).
Contribution guidelines for docs. I sort of think that the only way to solve this is by making thing so simple that they require fewer docs. The number of people and the amount of docs would make this a full time job to administer. Tedious.
Ergonomics. Again, I don't know if this is just the nature of the complexity or if there's actually some gnarly footguns in here. Best solution would be to keep cutting until it's very barebones. But is what you're left with useful?

To synthesize, I think that the largest issue is compiling and environment on Windows and I think that that is largely because most of these packages were never compiled on Windows. The simplest solution would be to ship static binaries for all packages with native modules. Would be interesting to see, from the existing set of luarocks, how many are source rocks that expect to be compiled and how much work it would be to convert those to binaries for all supported architectures. Does that then allow you to basically shim the existing ecosystem? Do you even need to fix compilation if you can just download packages with a CLI without needing a compiler?

Here's a first pass at a dump of the luarocks root manifest.

There are 26326 total package-version combinations.

Of those, 11308 use a "non-simple" build type (not "builtin" or "none"). Take this with a grain of salt. "builtin" packages can still indicate that a compilation step must take place. And also people misuse this field like crazy and it is apparently not validated so it is probably a very noisy metric. To wit, 8556 packages use a built type that is not outlined in the rockspec format specification but, as you will see later, that spec is pliable with regards to build types.

34 of the packages in the root manifest have a syntax error in their rockspec or are otherwise malformed. However, many of these are just that they have a shebang at the start of the file with two exceptions:

This one has a space in the name and is rejected by hosting server despite being in the manifest.
This one has no source rock or source URL. It purely metadata and would (hopefully) be rejected if submitted today.

There are some packages that report having platform-specific binaries (whether that's true or not) but it's very rare. Almost everything distributes source.

"win32-x86": 59,
"src": 21457,
"linux-x86_64": 2,
"macosx-x86_64": 75,
"kindlepw2": 1,
"macosx-x86": 1,
"all": 124,

My perspective at the end of this is that the flexibility and lack of validation in the luarocks package/build system means that there is generally not enough information present to ensure that a package can be compiled on a user machine.

Consider decasify. I've picked this at random because it uses a custom build system but it's also the development environment that I've most familiar with: Rust.

It depends on and correctly invokes the build system for rust-mlua. Rock: https://luarocks.org/modules/khvzak/luarocks-build-rust-mlua Source: https://github.com/mlua-rs/luarocks-build-rust-mlua/blob/main/src/luarocks/build/rust-mlua.lua

That would likely build on my machine. But it won't build on someone's machine if they don't have Rust installed. It won't build on someone's machine if they have an old version of Rust installed. And it will build but probably won't work on someone's machine if their native Rust target differs from the arch their Lua was compiled for.

Solvable? Definitely. Solvable on everyone's individual setups? Probably not.

So the question in my mind is: do we care about this package? Do we care about any of the packages that have as many downloads as this one does (~200 over the course of a year+)? Do we care about packages that use toolchains outside of C? Outside of C++? Outside of GCC? If we only cared about packages that could be compiled with GCC what additional information would the Luarocks package have to contain in order to ensure that it's compilable on a user's machine?

I think this is a pretty gnarly problem to tackle, holistically. I do think it is, partially, a package manager problem but I think that what information is required to be contained in that package is tough to know because of how dynamic these rocks are allowed to be. Maybe a collection of rocks that are difficult to compile on Windows but are well-used would be a good corpus to start looking more deeply at.

Nebula-Pack / RFCs

Motivation / Problem Statement #2