Skip to content

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

Closed

Description

@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.

Activity

  1. locked and limited conversation to collaborators on Feb 1, 2026
  2. converted this issue into a discussion #702 on Feb 1, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions