echasnovski
feat(ci): add automatic releases and publish to luarocks
Hey buddy, hope you're doing well!
I've been using mini.nvim for a long time now and absolutely love it. We are little by little working on the adoption of LuaRocks and I would like mini.nvim to be present there :)
Summary
This PR is part of a push to get Neovim plugins on LuaRocks.
- See this blog post, which follows up on a series of posts.
- See also:
rocks.nvim, a new luarocks-based plugin manager.
Things done:
- Add a
release-pleaseworkflow that creates release PRs with SemVer versioning based on conventional commits. - Add a workflow that publishes tags to LuaRocks when a tag is pushed.
The workflows are based on this guide by @vhyrro.
Notes
- On each merge to
master, thereleaseworkflow creates (or updates an existing) release PR. - You decide when to merge release PRs. Doing so will result in a SemVer tag, and a GitHub release, which will trigger the
luarocksworkflow. - For the luarocks workflow to work, someone with a
luarocks.orgaccount will have to add their API key to this repo's GitHub actions secrets, as mentioned in the guide mentioned above.
Thanks for taking time to create this!
I'll need time to weigh all pros and cons of this. Right now my thoughts are:
- I don't really agree with all three "negative" points of current status quo. Two of them are meant to be solved with Neovim specific packspec. Point about "copy pasting code is bad" doesn't really apply to 'mini.nvim'.
- I have never used luarocks and not sure what obligations (both formal and informal) it means for a person to upload there.
- To fully implement this, there also should be similar workflows in standalone repositories. Right now they don't have any workflows at all, which is easier to maintain.
I'll think about it (for, probably, a long time).
Hey :wave:
Author of the blog post here.
I hope you don't mind me adding some notes to this discussion. :smile:
Two of them are meant to be solved with Neovim specific packspec.
- I haven't seen any motion related to packspec since mid July this year (neither in the repo, nor in the Matrix channel).
- This is just my personal opinion, but it seems to me like the packspec is a reinvention of the wheel. I don't see it solving any problems that the luarocks rockspec (on which it was initially based) doesn't solve. It's supposed to be more generic (not tied to Neovim or Lua - which imho looks like it could turn into something like a less capable reinvention of Nix flakes).
From the packspec.org homepage:
If Nvim plugins can successfully use luarocks then pkg.json is redundant. pkg.json is only useful for ecosystems that don’t have centralized package management.
This is quite clearly the case. It even works for Vimscript plugins and packages that require compilation. Although to be fair, I do believe it would be harder to get Vimscript plugin authors on board, as some of them do not care very much for Neovim.
In any case, packspec and the luarocks approach do not preclude each other.
I have never used luarocks and not sure what obligations (both formal and informal) it means for a person to upload there.
For luarocks.org, there aren't really any formal obligations, beyond maybe the code of conduct.
Informally, I know of one shortcoming: If you are the owner of a package, and you decide to stop maintaining it, you are the only one who can remove it from the root manifest. That may be a bit of an issue if someone decides to take over maintainership and can't reach you.
This PR is based on @vhyrro's guide, which assumes you use conventional commits. Looking at your commit history, that does not appear to fit your workflow.
You do, however, maintain SemVer tags. So in case you do decide to accept this PR, I would suggest to remove the release-please workflow (the luarocks upload workflow would need some tweaks to work with it anyway).
Then there's no need for conventional commits.
I've been publishing my plugins to luarocks for about a year now (most of them without release-please), and I have never had to do any workflow maintenance (beyond maintaining/improving the GitHub action itself). Of course, my plugins' user bases are nowhere near as large as yours, so take this with a grain of salt.
Point about "copy pasting code is bad" doesn't really apply to 'mini.nvim'.
It may not apply to mini.nvim, but whether or not somebody else wants to reuse code from a mini.nvim module is outside of your control.
If this "push" does end up being successful, you may find some useful libraries on luarocks.org yourself. As an example, rocks.nvim now uses fzy to implement efficient native fuzzy auto-completions for packages on luarocks.org, without users having to worry about installing anything.
To fully implement this, there also should be similar workflows in standalone repositories. Right now they don't have any workflows at all, which is easier to maintain.
+1
Thanks for adding new information!
I haven't seen any motion related to packspec since mid July this year (neither in the repo, nor in the Matrix channel).
This is just my personal opinion, but it seems to me like the packspec is a reinvention of the wheel. I don't see it solving any problems that the luarocks rockspec (on which it was initially based) doesn't solve. It's supposed to be more generic (not tied to Neovim or Lua - which imho looks like it could turn into something like a less capable reinvention of Nix flakes).
Having no activity now doesn't mean there will be none in the future. I personally have been interested in this project and currently am thinking of ways to revive it.
I am all in favor of having some centralized way of installing plugins (my personal preferred reference is CRAN for R packages). However, Neovim core explicitly stated that Neovim as a project is not interested in creating and maintaining one.
Using luarocks as such centralized repository is only reasonable (for me) if it won't require installing a tool specifically to manage Neovim plugins. Right now all that is needed for managing plugins is Git, which is a pretty universally installed tool for most target users at this point (even if not, having it installed is usually beneficial). I don't like the idea of having to install luarocks just to install and update my plugins.
Ideally, Neovim should have its own built-in way to install/update/remove plugins.
If this "push" does end up being successful, you may find some useful libraries on luarocks.org yourself. As an example, rocks.nvim now uses fzy to implement efficient native fuzzy auto-completions for packages on luarocks.org, without users having to worry about installing anything.
Sorry, but I don't think so. 'mini.nvim' specifically designed to use as minimum dependency as is feasible. Ideally none.
I don't like the idea of having to install luarocks just to install and update my plugins.
Understandable, that's a valid point. I don't see how packspec will solve that problem though. After all, a tool (plugin manager) would be needed to implement it.
Ideally, Neovim should have its own built-in way to install/update/remove plugins.
Both luarocks and a tool that implements packspec could in theory be bundled with Neovim (or embedded?). But they might be too large...
'mini.nvim' specifically designed to use as minimum dependency as is feasible. Ideally none.
Fair enough :smile:
Just to be clear, Neovim core is very lukewarm on luarocks per se, to the point where we (had to) work hard to remove it completely from our build system because it just kept breaking (and there was zero interest upstream in fixing their issues). We've also significantly expanded the "Neovim standard library" and support for interacting with system tools, diminishing the need for external binary dependencies. Hence you won't see any support for it from us. Instead -- as @echasnovski wrote -- the aim is to have a minimal package manager module built around git/curl in core; the challenge is to precisely delineate what "minimal" entails. (I expect that once this is solved, the packspec issue will resolve itself as a consequence.)
This is a bit off-topic here, but as @echasnovski is also writing a plugin manager that follows a similar goal, I thought it germane.
(All that being said, I'm happy to see rocks.nvim's bootstrapping, which eliminates a huge pain point of previous efforts -- namely hererocks, which is an abomination. Still, it's way too heavy to include in Neovim core, for the same reason we are not interested in bundling nvim-treesitter's compilation logic.)
Yep, that's why I mentioned "they might be too large" 😅. And luarocks in neovim core is not what we are advocating for.
I was disappointed to see that the luarocks-api branch has disappeared; I'd been hoping for a more lightweight package that doesn't come with all the bulk for packaging and testing. But I have no idea how heavy such a package would have been...
there was zero interest upstream in fixing their issues
I have seen some of my longstanding issues get resolved recently.
Thanks again for the PR and suggestion, but I don't see LuaRocks being a host for significant number of Neovim plugins. Mostly due to friction for plugin authors to actually upload it and keep an eye on it. For now I'd prefer sticking with GitHub and current release approach (stable branch plus tags).
Closing as not planned.