search

nvim-neorocks / rocks.nvim

🌒 Neovim plugin management inspired by Cargo, powered by luarocks
GNU General Public License v3.0
650 stars 11 forks source link

warn when switching backends #476

Closed teto closed 1 month ago

teto commented 1 month ago

I had first installed smart-open.nvim via git. Then I uploaded a rockspec to luarocks.org and biw I dont remember exactly but I think I ran Rocks install smart-open.nvim and it replaced the rocks-git -based install of smart-open without warning (the folder remains in packpath though). I dont know what behavior we prefer but I think we might want to at least warn the user when doing so. And maybe Rocks sync should clean the packpath like Lazy does (or was that Lazy clean ^^'' ?)

mrcjkb commented 1 month ago

I dont know what behavior we prefer but I think we might want to at least warn the user when doing so.

That's a tricky one, because rocks.nvim isn't aware of any of its extensions. We could make sure rocks.nvim checks if there's a registered handler if there's an existing rocks.toml entry.

Generally, Rocks install "asks" for a handler (and rocks-git responds if it can construct a git uri from the argument). So the assumption when calling Rocks install with an argument that isn't a git URI or Github shorthand is that you want to install the luarocks package. I'm not sure if it's necessary to warn here (yagni), as it's unlikely someone will do this by accident, so warning just adds complexity.

And maybe Rocks sync should clean the packpath

Yes, rocks-git.nvim should clean up any packpath entries that don't have a corresponding rocks.toml entry with a git field on sync. Perhaps we could also add a handler API for hotswapping (i.e. cleaning up after) on install.

mrcjkb commented 1 month ago

Closing as yagni for now.

Yes, rocks-git.nvim should clean up any packpath entries that don't have a corresponding rocks.toml entry with a git field on sync. Perhaps we could also add a handler API for hotswapping (i.e. cleaning up after) on install.