[Feature Request] Add Lua Rocks for rocks.nvim

[EmDash00]

Would be great if we could get a Lua rock up with the new rocks.nvim package manager.

[benlubas]

Yeah, but how? this is a plugin built with python, it has python dependencies which rocks cannot install.

I've seen there are some tools to package python applications (and their deps) into a single binary but I haven't spent too much time looking into them b/c I just don't think that it's worth it (not to mention that I'm not sure it will work b/c it needs to (should) use neovim's python3 path). Rocks.nvim folks can still install this plugin from git.

If you have any suggestions or want to look into it I'm happy to start a conversation and help out if you find a way to do it.

[EmDash00]

I know poetry exists and I use that. I can look into the process to see if it's possible. Would greatly simplify the install process for most people since you can include image.nvim as a dependency. I'll go ask the rocks.nvim folks to see if they have thoughts.

[benlubas]

Thanks for looking into it. Ping me when you ask so I can keep an eye on it, simplifying the install process would make my life a lot easier

[mrcjkb]

Hey :wave:

one of the rocks.nvim maintainers here. I've been browsing through this plugin's docs. Here are my thoughts so far:

• The recommended way to install the python dependencies is into a virtualenv. Something like a luarocks-build-poetry-nvim build backend for luarocks could potentially solve this. We have similar build backends for tree-sitter parsers and for Rust/mlua projects.
• However, it looks like Neovim would need to be configured to use the venv. This is a manual step that I don't see as being possible to automate with luarocks.
• Another issue: Installing a luarocks package shouldn't pollute anything outside of the install tree.
  • Creating a ~/.virtualenv/neovim violates this principle.
  • Installing python packages globally also violates this principle.
  • Creating a ~/.local/share/nvim/rocks/.virtualenv doesn't.
• An option might be to for the build backend to create a virtualenv in the luarocks install tree. And rocks.nvim could configure Neovim to use that virtualenv. I'm not sure yet if this is a good idea. And there's still the open question about how or whether to clean up the python dependencies on removal.
• As of today, it appears that this plugin requires a manual installation of the python dependencies, regardless of which plugin manager is used to install it. So maybe it makes sense to publish it to luarocks first, with only Lua dependencies, and then to worry about the python dependencies later?

[benlubas]

idk, I don't see any real advantage to using luarocks. This plugins only lua dependencies are optional. The python deps are the only required ones, and luarocks provides nothing there. Publishing on luarocks might just lead to confusion.

I'm considering a rewrite of this plugin to use rust with mlua to avoid python and remote plugins as a whole, at which point I will absolutely publish on luarocks.

[mrcjkb]

Does any functionality not work without any of the image providers being installed? If so, then adding one of them to the luarocks dependencies as a default provider can improve the user experience (as long as it's possible to override the setting).

rocks.nvim installs dependencies as libraries, not plugins. So adding an optional dependency as a default isn't a big deal like it is for conventional plugin managers.

[benlubas]

Images don't render in this plugin by default b/c they're really janky. But yeah, without image.nvim or the wezterm plugin, images can't render in the terminal