Support LazySpec

[pedrohgmacedo]

It seems like rocks does not work with a lot of plugins. Take oil.nvim, a popular plugin that is also present in the rocks 'repository'. It does not work without a setup call. With lazy.nvim's spec, you can easily configure and load a plugin (without caling require("foo").setup {}) on:

• keypresses
• events
• filetypes
• commands
• custom conditions

Pretty much any plugin manager these days allow some level of control. Lazy.nvim is the de facto standard, and a lot of plugins are simply built targetting it. Rocks nvim claims to simplify plugin management, yet, a simple lazy.nvim table (which is not much different from a toml file):

return {
    "stevearc/oil.nvim",
    event = "BufEnter",
    keys = {
      {
        "-",
        "<CMD>Oil<CR>",
        mode = { "n" },
        desc = "Open parent directory.",
        noremap = true,
        silent = true,
      },
    },
    opts = {
      columns = {
        "icon",
      },
    },
    version = false,
  }
}

Becomes what??

[mrcjkb]

rocks.nvim is very different than lazy.nvim.

LazySpec is highly opinionated, and comes with high complexity on the implementation side (state management, merging, ...). We prefer the UNIX philosophy of doing one thing and doing it well.

See: rocks.nvim#Philosophy

For something similar to LazySpec for lazy loading, we have an open issue: https://github.com/nvim-neorocks/rocks.nvim/issues/87

Also, see: rocks.nvim#Should I lazy load plugins?

[pedrohgmacedo]

We prefer the UNIX philosophy of doing one thing and doing it well.

What thing is rocks.nvim doing well?

[mrcjkb]

We prefer the UNIX philosophy of doing one thing and doing it well.

What thing is rocks.nvim doing well?

We describe it in detail in rocks.nvim#Introduction.

The point is that rocks.nvim focuses on providing a bridge between neovim and luarocks, which is the de facto standard plugin manager in the lua ecosystem. That's its only concern.

Package management, configuration and (lazy) loading are three separate concerns. rocks-config.nvim is only concerned with configuration, not package management or loading.

Some people prefer to use Neovim's built-in mechanisms for these things, for a variety of reasons. One such reason could be not wanting to be tied to an ecosystem. By splitting rocks.nvim into pluggable extensions, these users aren't forced to run rocks-config.nvim's initialisation logic at startup.

Maybe one day someone who has another preference will write another rocks-xyz extension. In fact, there's nothing preventing anyone from writing a "rocks-lazy-spec.nvim". That someone just won't be me, because I'd have no use for it personally, and my philosophy is very different from folke's (not saying folke's is wrong, just different 😅).