[Module]: rocks-git for pulling plugins that don't exist on luarocks

[vhyrro]

Not everyone must have their plugins present on luarocks. This module would allow users to specify a git repository for installation of their plugins:

[plugins.neorg]
git = "nvim-neorg/neorg"

# or...

[plugins]
neorg = { git = "nvim-neorg/neorg", version = "1.0.0" }

[linrongbin16]

this feature would definitely help more users migrate to this plugin manager.

and how does this module behave when there are two plugins depend on a same git repository, but with different versions/tags/branches?

for example now I have two plugins:

• linrongbin16/fzfx.nvim
• linrongbin16/gitlinker.nvim

they all rely on a dependency:

• linrongbin16/commons.nvim

with different version 1.6.* and 2.*.

(actually I had upload the commons.nvim to luarocks, but) what if the dependency is not upload to luarocks?

can rocks.nvim support isolated versions on the same dependency?

[mrcjkb]

Some things to consider:

• Do we want to use packages (type = opt | start, like minpac, paq, ...)?
• Or should we use a rockspec template to generate a simple rockspec (like we do with luarocks-tag-release) and hook into the rocks install?
• Or both (type = opt | start | rock)?

Personally, I like the idea of generating a rockspec.

[mrcjkb]

and how does this module behave when there are two plugins depend on a same git repository, but with different versions/tags/branches?

I think dependeny management should be outside the scope of this module.

The point of rocks.nvim is to take away that burden from the user and make it the plugin authors' responsibility.

So we just need to rigourously package plugins that have dependencies (there's not that many at this point) for luarocks, so they can be installed without the rocks-git module.

[mrcjkb]

can rocks.nvim support isolated versions on the same dependency?

luarocks can install different versions of the same package, but I don't know at this point if it causes issues at runtime. My guess would be that a require will load the first module it finds on the path, which indeed would be an issue.
I don't know if luarocks reports on that though...

We should probably include some kind of dependency conflict detection at least in the health checks.

[linrongbin16]

can rocks.nvim support isolated versions on the same dependency?

luarocks can install different versions of the same package, but I don't know at this point if it causes issues at runtime. My guess would be that a require will load the first module it finds on the path.

We should probably include some kind of dependency conflict detection at least in the health checks.

maybe first investigate if isolated runtime path is supported by Neovim.

in second thought, maybe it's not supported at all in Neovim. I never read relate things in Neovim documents.

---

update:

based on intuition, I guess Neovim is just appending plugin folder to its runtime path, so let lua require can correctly find the plugin source code (include other things e.g. plugin, autoload).

Thus provide different runtime path for different plugin seems not possible. Because one process (Neovim editor instance) only have one environment path $PATH.

To support different runtime path, a plugin will have to run in a isolated child process, e.g. a remote plugin.

---

update-2:

but how does lua and luarocks community (without considering Neovim) handle such case?

If there are two luarocks packages: a and b, they all depend on the third luarocks package c, with different versions, for example 1.* and 2.*.

How does lua handle the runtime path itself?

[mrcjkb]

We don't add dependencies to the rtp, just to the package.path and package.cpath.

But it looks like luarocks handles conflicting dependencies as it should.

[linrongbin16]

We don't add dependencies to the rtp, just to the package.path and package.cpath.

But it looks like luarocks handles conflicting dependencies as it should.

then it should be all good, at least luarocks itself solved dependencies with different versions correctly.

this issue happens all the time, in all programming languages and package managera: java and maven/gradle, ubuntu and apt, cpp and cmake.

[mrcjkb]

Starting work on this...

Personally, I like the idea of generating a rockspec.

On second thought, this could potentially lead to conflicts with luarocks installations.
I will stick with packages.