query: clarification: Plugins requiring a build step AND the user event RocksInstallPost

[120ace]

Hi. This is primarily 2 overall questions:

1)

Looking through your readme and :help rocks-nvim I do not see any direct directions for making the equivalent of a build post install/update function.
I do see a user event defined as so:

vim.api.nvim_create_autocmd("User", {
       pattern = "RocksInstallPost",
       callback = function(ev)
       ---@type rocks.user-events.data.RocksInstallPost
      local data = ev.data
      -- ...
   end,
})

However, the :help is not clear as to what is inside ev.data, nor whatever-else it may contain.
Looking at your readme, there is a reference to rocks-git.nvim, which when going to it's page clearly shows the simple setup needed for build. But, there is no direct mention of this in the rocks.nvim readme.
I think this would be helpful to mention in your rocks.nvim readme.

What is inside ev.data? And how would I use it? Nvim 0.12 nightly gives a decent enough example of how to extract the name and type of action from their PackChanged events ev.data.

Thinking about this further, I don't actually understand how plugins packaged using luarocks/lux-cli handle this problem, leading to my second question.

2)

How do plugins packaged using luarocks/lux-cli handle this? When you download their package, do these things come prebuilt, or does the package manager build them on system?

Speaking specifically to lux-cli, I think I remember remember seeing it has support for building your Rust dependencies along with mlua. However, what about plugins that require build steps for languages other than C/Rust? Would those plugins only be available as git plugins, or would rocks.nvim still be able to handle them as Lua packages? This is something I am very much wondering about right now.

---

Thank you for this project, lux-cli, and all the work you guys are doing for improving the Neovim ecosystem. I understand that this specific project is undergoing a major rewrite to use lux-cli rather than luarocks. As such, if the answers provided are for how the rewrite plans to handle these things rather than how they currently are, I would still be more than happy for knowing.

[mrcjkb]

Hey 👋

1)

Yes, RocksInstallPost can be used as a hack for packages that require an extra build step and don't specify one to be executed by LuaRocks.
Typically, you should only need to do this with plugins that are not packaged for LuaRocks and which you have installed using rocks-git.nvim.

The rocks.nvim help page links to:

RocksInstallPost			            Invoked after installing or updating a rock
                                     The `data` is of type
                                     |rocks.user-events.data.RocksInstallPost|.

from which you can navigate to the follwing by following the tags (<C-]> on the |rocks.user-events.data.RocksInstallPost|):

                                       *rocks.user-events.data.RocksInstallPost*
rocks.user-events.data.RocksInstallPost

    Fields: ~
        {spec}       (RockSpec)
        {installed}  (Rock)

RockSpec : TomlRockSpec                                               *RockSpec*

    Fields: ~
        {name}  (string)  The name of the rock


Rock                                                                      *Rock*

    Fields: ~
        {name}     (rock_name)
        {version}  (string)

TomlRockSpec                                                      *TomlRockSpec*

    Fields: ~
        {version?}       (string)    The rock version
        {opt?}           (boolean)   Set to `true` to prevent rocks from being loaded eagerly
        {pin?}           (boolean)   Pinned rocks will not be updated
        {install_args?}  (string[])  Additional args to pass to `luarocks install`
        {string}         (unknown)   Fields that can be added by external modules

Note that RockSpec : TomlRockSpec means that RockSpec extends the TomlRockSpec type, i.e. it has all the fields plus the name field.

2)

do these things come prebuilt, or does the package manager build them on system?

The package manager builds them on the system, unless you specify a binary repository (which rocks.nvim does), in which case pre-built packages that are available on the binary repository will be fetched.

However, what about plugins that require build steps for languages other than C/Rust? Would those plugins only be available as git plugins, or would rocks.nvim still be able to handle them as Lua packages? This is something I am very much wondering about right now.

That is up to the plugin authors. LuaRocks and Lux support various built-in build backends (builtin, make, script, cmake, ...) and also custom build backends, which themselves are published as LuaRocks packages and fetched/invoked at build time.
For example, the luarocks-build-treesitter-parser build backend can use the tree-sitter CLI to build tree-sitter parsers.
There are various custom build backends on luarocks.org.