Repo enhancements for better SBOM support

[gitgitwhat]

I wish I could PR this but I have no idea what MoonScript, Lapis or Tup are so unfortunately I can't be much help but I'm hoping these requested features won't be difficult.

This repo and lack of API make it hard for SBOM tools to capture package details. Most repos have an API or just the ability to get a JSON/XML file that contains the important details of a package like release versions along with release date, license, etc. The best that Luarocks seems to provide is a version specific rockspec. Rockspecs have a lot of information but are missing key details like release dates.

The challenge though is when you get a Luarocks PURL, you might not be able to resolve the right page. If you look at the Luarocks PURL spec (https://github.com/package-url/purl-spec/blob/main/types-doc/luarocks-definition.md) you'll see two examples:

pkg:luarocks/luasocket@3.1.0-1
pkg:luarocks/hisham/luafilesystem@1.8.0-1

The luafilesystem example has a username which let's you navigate to the appropriate page (https://luarocks.org/modules/hisham/luafilesystem). From here you can parse the HTML and get pretty much everything you need. So, first feature request would be to actually list the release/update datetimes in the page instead of as tooltips. Not that we can't work around that but it seems like an easy thing to implement.

The other example does not have a username and this is where it gets tricky. What you can do though is craft a rockspec URL from that information which in this case would be (https://luarocks.org/m/root/luasocket-3.1.0-1.rockspec). Again, that gets us some information but still missing release date as well as any 'owner' field that would then let us create a fully formed address (https://luarocks.org/modules/lunarmodules/luasocket)

The rockspec address you find on the /modules/ page (https://luarocks.org/manifests/lunarmodules/luasocket-3.1.0-1.rockspec) is equivalent to https://luarocks.org/m/root/luasocket-3.1.0-1.rockspec but there's no way to translate from the /m/root to the other.

As much as an API would be nice I realize that's a bigger effort but if there would be a way to implement either a redirect or mirror so if all I have is the package name, I can still land at the main package page. From there I can just BeautifulSoup it to get the data I need.

I reviewed the luarocks cli to try and understand how it works but I'm not Lua proficient so I may have overlooked something simple. Hopefully that's the case.

[leafo]

As much as an API would be nice I realize that's a bigger effort but if there would be a way to implement either a redirect or mirror so if all I have is the package name, I can still land at the main package page. From there I can just BeautifulSoup it to get the data I need.

Module names are only unique to the manifest they live on. Each user account has an implicit manifest which contains all of their own modules. A single module can be in any number of manifests. The luarocks CLI pulls form the root manifest by default.

As a quick example, the root manifest for Lua 5.1 is located here: https://luarocks.org/manifest-5.1 or https://luarocks.org/manifest-5.1.json

From there you have "module" -> "version" -> "rock" hierarchy for the necessary components for a module.

As an example, we'll take the lapis package in the root manifest: https://luarocks.org/modules/leafo/lapis

In the manifest we have an object like:

   "lapis": {
      "1.8.1-1": [
        {
          "arch": "rockspec"
        },
        {
          "arch": "src"
        }
      ], ...

From there we can construct file paths to access key components of the module, for example 1.8.1-1 publishes a rockspec and a src rock:

• https://luarocks.org/manifests/leafo/lapis-1.8.1-1.rockspec -- A lua file that specifies what the module with instructions for luarocks to install it
• https://luarocks.org/manifests/leafo/lapis-1.8.1-1.src.rock -- Zip file containing all the sourcecode

I agree that a separate API beyond what the luarocks CLI uses to install something could be helpful for additional metadata like publish date, just querying just a single module's versions.