Closed teto closed 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
.
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.
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 ^^'' ?)