What about packspec (pkg.json)?

Some Neovim users / plugin authors campaign against luarocks adoption, because they believe it will be made redundant by packspec/pkg.json.

Tip

Don't worry, you can still find their plugins on luarocks, thanks to the NURR.

To address some of those concerns:

• pkg.json and luarocks adoption are not mutually exclusive.

I see packspec (or whatever "wild west half-baked dependencies declaration format") as merely a high-leverage, low-effort way to start formally connecting the existing web of vim/nvim dependencies. It doesn't preclude a luarocks approach at all, it simply formalizes what already exists--assuming it gets any traction.

• From the packspec.org spec page:

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.

• Luarocks will likely never be bundled with Neovim.
  • Instead, we bundle it with rocks.nvim.
  • You only need to bootstrap a temporary installation, which currently works well on most UNIX-like systems.

Why do we prefer Luarocks?

• Packspec's main strength is:

LuaRocks is a "centralized" approach that requires active participation from many plugins. In contrast, pkg.json is a decentralized, "infectious" approach that is useful at the "leaf nodes": it only requires the consumer to provide a pkg.json, the upstream dependencies don't need to be "compliant" or participate in any way.

[packspec readme]

• This quickly stops being the case with transitive dependencies. For example, if

  • plugin X depends on library Y and library Y has any dependencies
  • library Y does not contain a pkg.json

  a packspec-compliant plugin manager will pull library Y without its dependencies.

  Decentralized package management has seldom been successful due to technical problems with the approach (see all the most popular programming languages we use today).

• In fact, the notion that luarocks is completely centralized is a myth. It allows the configuration of rocks_servers, which can be anything from a remote server to a set of files on someone's filesystem.

• Concerns about an initial lack of luarocks adoption can be (and have been) addressed by the fact that package maintainers and plugin authors don't need to be the same entities.

• Luarocks has the ability to build and package plugins. With this, we can precompile binary rocks so you don't have to. This is out of scope for pkg.json and would require out-of-spec fields or alternate specs, which is not scalable to other plugin managers (see EEE).

• Luarocks is a full-fledged package manager that supports the coexistence of different versions of the same dependency.

• Luarocks is the battle-tested status quo for Lua packages. It actually has a pretty big head start outside of the Neovim ecosystem, therefore trying to reinvent the wheel is not incentivized (see the NIH syndrome :p).

• There are plethora of premade utility rocks on luarocks.org, which could greatly speed up the creation of plugins by relying on tested, existing code, instead of copy/pasting or relying on a hand-rolled implementation.

• Packspec is in Alpha and incomplete.

  • Its development is slow (almost stale as of writing this).
  • Its "What about Luarocks?" section is outdated.

• If packspec does end up being adopted by a lot of plugins, rocks.nvim's modular architecture would make it easily extensible with a "rocks-pack.nvim" module, giving you the best of both worlds.

Some more benefits of Luarocks:

• Reusable, custom build backends (e.g., luarocks-build-rust-mlua, which we use to build toml-edit).
• Proper separation of SemVer releases and dev/scm rocks into their own manifests.
• Separation of RockSpecs and source rocks on luarocks servers. With packspec, a package manager must checkout all sources, just to resolve all dependencies.