search

alexghergh / nvim-tmux-navigation

Easy Neovim-Tmux navigation, completely written in Lua
MIT License
313 stars 22 forks source link

`rocks.nvim` #25

Closed sahinf closed 2 weeks ago

sahinf commented 5 months ago

Hi,

Would you consider packaging this nvim plugin to LuaRocks? That would allow rock users like me to easily install this package with :Rocks install nvim-tmux-navigation The rocks.nvim team setup a github action that publishes packages to LuaRocks to make it easier.

alexghergh commented 5 months ago

Hey,

I'm not sure what the differences are between LuaRocks and the normal way of installing plugins via e.g. lazy.nvim. Is there a significant advantage to using rocks? I understand that LuaRocks is specifically used for packaging Lua modules. This plugin doesn't really make sense outside of Neovim/Tmux though, so I don't really see a reason to package it as a rocks module.

Though, I may be wrong. Please do let me know if you consider the above wrong. If the reasons are enticing and there are benefits, I can absolutely consider packaging it as a LuaRocks module.

Thanks!

sahinf commented 5 months ago

I'm not sure what the differences are between LuaRocks and the normal way of installing plugins via e.g. lazy.nvim

I should have included a link to the blogpost that convinced me to begin experimenting with LuaRocks. It's about 1 minute of reading if you wouldn't mind giving it a glance.

Is there a significant advantage to using rocks

Just from a user standpoint. I can install and play around with LuaRocks packages through :Rocks install <package> with autocompletion support for the list of packages, then start using it right away without extra configuration. rocks.nvim puts the burden of managing dependencies, lazy loading, and initial setup on the package developer rather than the package user.

This plugin doesn't really make sense outside of Neovim/Tmux though, so I don't really see a reason to package it as a rocks module.

I agree that the plugin doesn't make sense outside of neovim, but all neovim plugins don't make sense outside of neovim, implying that integrating neovim into the greater LuaRocks ecosystem doesn't make sense. I disagree.

  1. Tapping into LuaRocks allows neovim package developers to leverage a wide range of libraries from active Lua developers rather than duplicating code into their own packages.
  2. LuaRocks supports isolated virtual environments like python, greatly simplifying dependency conflicts when developing packages.
  3. When installing a rocks package as a user, I don't have to worry about dependencies.

But given the recency of rocks.nvim (low userbase right now) and the extra work required to package it, I understand if you would rather not. I started using a different nvim/tmux package already packaged for LuaRocks. But, I'd prefer to use your rewrite of christoomey's.