`Rocks packadd`: fall back to built-in `packadd`

[xsh005]

Sorry for spamming three issues in a single day TT

Since rocks-git introduces site/pack/rocks/, Rocks packadd should take that into consideration and look at both site/pack/rocks and rocks/lib/luarocks/rocks-5.1. rocks-git should probably override the subcommand when loaded :thinking:

Thank you very much for your time! When the rough edges are sorted with I would like to make a custom loader for rocks.nvim (which also has to somehow work around the awkward opt = true unfortunately)

[mrcjkb]

Hey 👋

No need to apologize. The more feedback we get, the better 😃

By design, rocks.nvim isn't supposed to know about its extensions. You can use the built-in :packadd[!] for plugins installed with rocks-git.

But it might be a good idea for :Rocks packadd to fall back to the built-in :packadd if there's no rock.

@NTBBloodbath @vhyrro @teto what do you think?

[vhyrro]

Yeah that makes a lot of sense, I'm on board with the change. Rocks's packadd should be a layer on top of packadd, not a replacement, so falling back is very sensible :)

[xsh005]

Thank you!

[xsh005]

Should we wrap this in pcall when error_on_not_found is false :thinking: ?

https://github.com/nvim-neorocks/rocks.nvim/blob/33d852102566c57575946564006e2dcb8f472a6b/lua/rocks/runtime.lua#L135

[mrcjkb]

Should we wrap this in pcall when error_on_not_found is false 🤔 ?

https://github.com/nvim-neorocks/rocks.nvim/blob/33d852102566c57575946564006e2dcb8f472a6b/lua/rocks/runtime.lua#L135

I don't think that's necessary? Afaik, the built-in packadd doesn't fail if a package isn't found. And it could error for various other reasons (e.g., if one of the plugin's runtime files errors). We wouldn't want to catch that.