luarocks-tag-release workflow?

[mrcjkb]

@teto and I are trying to promote the use of LuaRocks to distribute Neovim plugins.

• See this blog post, which follows up on a series of posts by @teto.

Would you be open to a PR that adds the luarocks-tag-release GitHub action to this template?

By now, it has matured enough that most Neovim plugins only need to add the action, without any inputs.

Its use could be seen as controversial, because:

• It requires a LuaRocks account and a LUAROCKS_API_KEY that needs to be added to a repostory's GitHub Actions secrets.
• The default implementation assumes tagged releases. Though, a rolling-release workflow is also possible with some extra configuration.

[matu3ba]

Can you provide a brief overview and comparison to https://github.com/nvim-lua/nvim-package-specification ?
I'm still missing something like luarocks update --all, but I see the point of having a separate package index.

[mrcjkb]

@matu3ba Sure 😄

The workflow doesn't define any specification. I uses the existing rockspec format, which has been well-established in the Lua ecosystem (it's the de facto standard).

It's difficult to build an opinion on the Neovim package spec, because it's still WIP.
So I can only give you my (opinionated) thoughts based on what I know about the current status.

• The PackSpec specifies support for source = luarocks:// in its schema. When it is finished, it should be compatible with LuaRocks, so I don't see a conflict between the two approaches.
• PackSpec is based on RockSpec, and from what I can tell, the only thing it adds is the ability to install plugins using a larger number of source protocols. RockSpec can install from luarocks.org, and scm if enabled with the --dev flag.
• luarocks has the ability to build and package plugins.
  With the luarocks-tag-release workflow, you can build non-lua binaries in GitHub CI (using make or cmake), and distribute them with your plugin. No need to tell users to manually build them after installing from scm.
• luarocks is a full-fledged package manager that supports the coexistence of multiple dependencies with different versions.
• There's a good reason there's no luarocks update --all: To minimise dependency hell. PackSpec won't solve that problem.
  If you specify plugins as dependencies in a rockspec, you can pin them with a lock file and update them with the --pin flag.
• PackSpec defines a version in its schema; and the readme says plugin authors should have a git tag that matches that version. I don't agree with that UX. What if you want the version on your main branch to be scm or dev? Some plugin authors don't want to maintain tags, but prefer rolling releases. All of these use cases are supported by RockSpec. The luarocks-tag-release action supports them too, and solves the pain point of polluting your repository with multiple version-named rockspecs.
• This is just my personal opinion, but it seems to me like the PackSpec is a reinvention of the wheel. I don't maintain a Neovim plugin manager though, so I could be overlooking something. In any case, I don't believe there's a conflict.
• I believe we can solve the pain points much faster if we take the LuaRocks route. And when PackSpec is ready, plugin managers that implement the full spec should support LuaRocks anyway (although luarocks would probably be the less bloated option).

[mfussenegger]

It requires a LuaRocks account

Do you have an idea how to handle that? It should at least not cause failures if the credentials are missing.
I think assuming tagged releases is fine (and actually good that it doesn't do anything if there are no tags).

[mrcjkb]

The action will (and should) fail if the API key is missing.
But one could add

if: env.LUAROCKS_API_KEY != null

to the step that runs the action. This would skip it if the API key isn't set.

and actually good that it doesn't do anything if there are no tags

We do have plans to add support for luarocks test and also testing luarocks install (and maybe upload) in PRs - which we will recommend. Otherwise the only way to test that the workflow doesn't break would be to merge and tag.

These could also be skipped if the API key isn't set.