Currently when running :Rocks update a message is only issued after the update checking is complete. It would be nice to first display a message like "Checking for updates..." before displaying anything else (i.e. "Nothing to update!").

Unrelated to this issue but when cloning luarocks maybe use --filter=blob:none, because it was so slow without it 😅

Originally posted by @tembokk in #166 (comment)

fidget.nvim, while quite nice, is more than just a notification framework, it would be nice if it can be decoupled. I just wrote my own vim.notify which has a similar look and feel to fidget, if no one is against this I am interested in a pr.

To reproduce:

• :Rocks install luasnip (writes luasnip to rocks.toml)
• :Rocks install haskell-snippets.nvim (depends on luasnip, writes haskell-snippets.nvim to rocks.toml)
• :Rocks prune haskell-snippets.nvim

Expected behaviour:

• haskell-snippets.nvim is removed from rocks.toml
• Only haskell-snippets.nvim is uninstalled.

Actual behaviour:

• haskell-snippets.nvim is removed from rocks.toml
• Both luasnip and haskell-snippets.nvim are uninstalled.

Workaround:

Run :Rocks sync.

Depends on #86.

Users could add things like events or filetypes to their plugin config, to load plugins lazily.

[plugins]
rustaceanvim = { version = "1.0.0", opt = true, filetypes = [ "rust" ] }

• Related: #53
• Respect the lazy config.

Hi! I like the idea of this project and wanted to try it but run into some issues. It's probably some stupid mistake on my part so I apologize in advance.

So, I used the command given in README (:source ...), and the installer page opened up, I didn't change the default values, clicked OK, and then I got the following messages.

Downloading luarocks...
Configuring luarocks...
Configuring luarocks failed:

Not everyone must have their plugins present on luarocks. This module would allow users to specify a git repository for installation of their plugins:

[plugins.neorg]
git = "nvim-neorg/neorg"

# or...

[plugins]
neorg = { git = "nvim-neorg/neorg", version = "1.0.0" }

If you come across a plugin that isn't on luarocks.org, and you think it should be, you can leave a comment here (or thumbs up on any open PRs).

Error detected while processing /home/xiaoshihou/.local/share/nvim/rocks/lib/luarocks/rocks-5.1/rocks.nvim/2.6.1-1/plugin/rocks.lua:               
E5113: Error while calling lua chunk: .../.local/share/nvim/rocks/share/lua/5.1/rocks/runtime.lua:72: attempt to call local 'type' (a string value)

Maybe it's a good idea to rename the variable type

After install/sync, run :helptags {rock|ALL}.

• Diagnostics for outdated rocks
• Code actions to update/downgrade a rock
• Completions, e.g. for rocks and versions
• Hover: luarocks show

Maybe this should be implemented as an external module?

Ton option to mitigate this would be to

• get the environment variable before running any luarocks commands
• unset it
• run the luarocks command
• reset it

Check if a sync handler can be found for each entry in rocks.toml and report an error if not.

The idea would be a rocks.api module that exposes functions for

• (fuzzy?-) searching installed rocks
• (fuzzy?-) searching rocks on luarocks
• Adding subcommands to :Rocks
• Get rocks.toml

so plugins could integrate with rocks.nvim, e.g. with a telescope picker.

To reproduce:

• :Rocks install luasnip 2.1.1
• :Rocks edit

Expected behaviour:

• rocks.toml contains: luasnip = "2.1.1-1"

Actual behaviour:

• rocks.toml contains: luasnip = "2.1.1-1:"

As the title says, whenever a plugin dependency gets updated through :Rocks update, it is added as a new entry to the rocks.toml entry, causing some unexpected junk entries.

This one is a bit more hard to reproduce so I cannot really give reliable reproduction steps here, hope it's not a blocker!

My nvim version: v0.10.0-dev-2388+gb12d193b4
I install lua and luarocks through scoop install lua-for-windows
Then on rocks.nvim installation I set Set up luarocks (recommended) ?: false
And I get this error

Installing rocks.nvim...
E5108: Error executing lua: ...m-nightly\current\share\nvim\runtime/lua/vim/_system.lua:241: ENOENT: no such file or directory
stack traceback:
	[C]: in function 'error'
	...m-nightly\current\share\nvim\runtime/lua/vim/_system.lua:241: in function 'spawn'
	...m-nightly\current\share\nvim\runtime/lua/vim/_system.lua:332: in function 'system'
	C:\Users\Windows 10\AppData\Local\Temp\nvim.0\ywhunR\0.lua:383: in function <C:\Users\Windows 10\AppData\Local\Temp\nvim.0\ywhunR\0.lua:357>

I think it would be very useful to support a lockfile to always install the plugins and their dependencies with the same version if you have to change the Neovim installation either because you installed your dotfiles on another machine or another reason.

Luarocks supports this natively, please take a look at Pinning versions with a lock file.

Currently, operations like Rocks sync fail if a single luarocks CLI operation fails (e.g. when Future.wait() errors).

Instead, we should

• Keep track of the errors, continuing if one fails
• Log errors to a log file that can be opened with :Rocks log
• Report if any errors have occurred (e.g. with the message Sync completed with errors. Run ':Rocks log' for details`).
• Or, at the end of an operation, in the event of an error, ask the user if they would like to open the log file.

This would mean two things:

• Change the installer to tell users to add vim.opt.runtimepath:append(vim.fs.joinpath(rocks_config.rocks_path, "lib", "luarocks", "rocks-5.1", "rocks.nvim", "*")) to their init.lua

• Add an option to lazy load plugins to rocks.toml (see below snippet)

[plugins]
neorg = { opt = true, version = "1.0.0" }

• Add a rocks.api.load_plugin(name) function :Rocks[!] packadd {rock} command that allows users or an external module to load plugins manually.

It takes multiple sweeps.

Example:

• Install haskell-snippets.nvim and luasnip
• Delete them from rocks.toml
• Rocks sync

Expected behaviour:

• Both plugins, as well as the jsregexp dependency are pruned

Actual behaviour:

• Only haskell-snippets.nvim is pruned. luasnip can't be pruned yet, if haskell-snippets.nvim isn't pruned first, because it depends on it.
• It takes more than one call to Rocks sync to actually prune all dependencies.

Potential solutions:

• Analyze dependencies, then figure out the order in which to prune rocks.
• repeat <pruning logic> until <no more rocks that depend on installed rocks left in to_prune list>.

same with title

The wait here does not exist, which will cause the plug-in initialization to fail.

Everybody knows fancy setup in GIF == plugin success. A GIF with a fully fledged config would definitely be more enticing :)

The code vim.loop.random(7) in the above possibly generates a directory name that is treated as invalid by the OS.
For example: luarocks-<a1><ec>^O<98>^^{<f8>.

Therefore, I suggest changing that line to the following:

local tempdir = vim.fs.joinpath(vim.fn.stdpath("run"), string.format("luarocks-%X", math.random(256 ^ 7)))

The problem is somewhat hard to describe, so I am going to try my best.
My ~/.config/nvim/after/ftplugin contains some configurations for plugins

dap.lua        
epo.lua        
guard.lua      
lspconfig.lua  
squirrel.lua   
telescope.lua  
treesitter.lua 

If I open nvim in that particular directory, I would get warnings like these:

E5113: Error while calling lua chunk: ./dap.lua:1: loop or previous error loading module 'dap'

dap.lua:

1 local dap = require("dap")

I suspect the lua loader module is confusing the local dap file with the dap directory in my rtp, causing an infinite require cycle.

Current Behaviour

Consider the following rocks.toml:

[plugins]
"sweetie.nvim" = { version = "xxx" }

Upon running :Rocks update, rocks.nvim will forcefully coerce the table down to the following:

[plugins]
"sweetie.nvim" = "xxx"

Expected Behaviour

rocks.nvim should only do this coercion if the type of the plugin is not a table.

This leads to partial uninstalls

To reproduce:

• Install a bunch of plugins.
• Remove all plugins from rocks.toml.
• Run Rocks sync.
• Wait for it to finish.
• Run Rocks sync again.

Expected behaviour:

• Progress message says everything is in sync.

Actual behaviour:

• An error message is displayed, saying the rockspec of a previously pruned plugin can\t be found.

This appears to be because of an incomplete uninstall.

Excample:

Error executing vim.schedule lua callback: ...pack/myNeovimPackages/start/rocks.nvim/lua/nio/tasks.lua:95: Async task failed without callback: The
coroutine failed with this message:
...ck/myNeovimPackages/start/rocks.nvim/lua/nio/control.lua:107:
Error: Could not load rockspec file /home/mrcjk/.local/share/nvimrocks/rocks/lib/luarocks/rocks-5.1/haskell-snippets.nvim/1.4.2-1/haskell-snippets.
nvim-1.4.2-1.rockspec (/home/mrcjk/.local/share/nvimrocks/rocks/lib/luarocks/rocks-5.1/haskell-snippets.nvim/1.4.2-1/haskell-snippets.nvim-1.4.2-1.
rockspec: No such file or directory)

stack traceback:
        [C]: in function 'error'
        ...ck/myNeovimPackages/start/rocks.nvim/lua/nio/control.lua:107: in function 'wait'
        ...ck/myNeovimPackages/start/rocks.nvim/lua/rocks/state.lua:112: in function 'rock_dependencies'
        ...NeovimPackages/start/rocks.nvim/lua/rocks/operations.lua:275: in function <...NeovimPackages/start/rocks.nvim/lua/rocks/operations.lua:1
54>
stack traceback:
        [C]: in function 'error'
        ...pack/myNeovimPackages/start/rocks.nvim/lua/nio/tasks.lua:95: in function 'close_task'
        ...pack/myNeovimPackages/start/rocks.nvim/lua/nio/tasks.lua:117: in function 'cb'
        ...pack/myNeovimPackages/start/rocks.nvim/lua/nio/tasks.lua:181: in function 'waiter'
        ...ck/myNeovimPackages/start/rocks.nvim/lua/nio/control.lua:81: in function 'wake'
        ...ck/myNeovimPackages/start/rocks.nvim/lua/nio/control.lua:99: in function 'set_error'
        ...ck/myNeovimPackages/start/rocks.nvim/lua/rocks/state.lua:106: in function ''
        vim/_editor.lua: in function <vim/_editor.lua:0>

I initially thought this was a rocks-git only issue (see nvim-neorocks/rocks-git.nvim#8),
but after making rocks-git async, I think there's something blocking the UI while the sync operation initialiazes.

• Neovim's checkhealth doesn't support luarocks packages. See neovim/neovim#26580.

• To work around this, we could implement a :Rocks checkhealth command, which searches the package.path for <rock>.health modules (perhaps based on the rocks in rocks.toml) and provides completions for rocks in rocks.toml.

• Both the command and completions should fall back to Neovim's built-in checkhealth (if args are passed to it)

• For Neovim's checkhealth without any args, rocks.nvim could use autoload/health.vim to run its own health checks + the ones for its plugins.

Currently we have a pretty decent and performant tab completion for all the available rocks on Luarocks while installing a new plugin, however, it doesn't work with keywords as we are using vim.startswith to filter rocks based on the user query (e.g. :Rocks install nvim will filter rocks that starts with nvim for completion).

However, we could highly improve it by adding some fuzzy filtering with fzy-lua which is also in Luarocks so we could easily add it as a dependency for rocks.nvim so instead of only matching rocks starting with nvim we could match any rock that contains nvim on its name.

The rocks' rtp directories are installed into a rocks.nvim-scm-1-rocks directory, for some reason.

I think this may be because the luarocks config from the rocks-nvim package is propagated to neovim's environment?

At the end of Rocks install, and Rocks sync, add the newly added plugins to the runtime path.

Perhaps this should be configurable?

Currently, the Updating... message of a second plugin overwrites the Updated message of the previous plugin (sync/update, ditto for Installing..., Downgrading..., ...).

To show the completed messages a bit longer, we could use two progress handles and alternate between them.

rocks.nvim will fail when trying to downgrade from a plugin installed with the development version (scm) to a semantic version of it.

Related files and lines of code:

• lua/rocks/operations.lua: 340-341

Reproduction steps

• Install any plugin that has a scm version like telescope.nvim by using :Rocks install telescope.nvim scm-1
• Edit your rocks.toml file and change the telescope.nvim version from scm to 0.1.5
• Run :Rocks sync command

Error traceback

Summary

If a plugin that other plugins depend on is removed from rocks.toml,
rocks.nvim attempts to remove it.

Spec

Given the following rocks.toml:

[plugins]
"haskell-tools.nvim" = "2.3.0" # depends on plenary.nvim
"plenary.nvim" = "0.1.3"

And both plugins have been installed with :Rocks install
When I remove plenary.nvim from the rocks.toml as follows:

[plugins]
"haskell-tools.nvim" = "2.3.0" # depends on plenary.nvim

And I execute :Rocks sync

Expected behaviour

Then nothing happens

Current behaviour

Then the rocks.nvim displays "Removing 'plenary.nvim'"

Implementation details

• luarocks does not have a way to list dependencies, but luarocks show <rock_name> will list the dependencies of each rock.
• We could use this on each rock in rocks.toml to gather all dependencies, and then filter the list of rocks to remove accordingly.

So, let's use just one plugin as an example. I just published 2048.nvim to luarocks. I installed it with :Rocks install 2048. And here comes the part that I'm interested in. By default rocks.nvim sources the lua/ directory of the plugin, but unlike lazy.nvim it doesn't automatically call the setup function (as far as I can tell). So I guess that the approach here would be something like this: I have one file with plugin declarations (rocks.toml) and configurations files (e.g. ~/.config/nvim/lua/plugins/2048.lua) where I call the setup function and do customizations if I want to. I know that this could be done in a million different ways, but I just wanted to understand the intended way of doing things and try to adapt to them so I can see the full picture. Let me know if I misunderstood something.

Note: I read the rocks-config.nvim docs, so I have a few more questions about that.

1. Does this:

[config]
plugins_dir = "plugins/"

do the same thing as I mentioned above (the ~/.config/nvim/lua/plugins/... stuff)? The difference could be that with rocks-config I don't have to manually source the configurations, but without it, I would need to have require('plugins') in ~/.config/nvim/init.lua and then in lua/plugins/init.lua lines such as require('plugins.2048') to source the file that contains my plugin config.

2. I understood that the auto_setup option is meant to be used when you don't want to pass any arguments to the plugin's setup function (in other words you are satisfied with the default config, or the plugin does not have any configuration options). So is this the equivalent to config = true or opts = {} in lazy.nvim? I'm sorry for creating parallels to lazy but that's currently what most people (including me) are familiar with.

luarocks will fail to install toml-edit.
Try to install it through the command line, the following prompt appears:

Neovim version: nightly

Try to run luarocks config , it outpus:

5.4 outputs: https://gist.github.com/jinzhongjia/0b1acc55bebd5a56a7e17f9a9df6f53e
with --lua-version=5.1 outputs: https://gist.github.com/jinzhongjia/bcfbda053813f8e2e8e3236e9b811cf8

Error executing Lua callback: ...oguz/.local/share/nvim/rocks/share/lua/5.1/nio/tasks.lua:95: Async task failed without callback: The coroutine failed with this mess
age:
error loading module 'toml_edit' from file '/Users/oguz/.local/share/nvim/rocks/lib/lua/5.1/toml_edit.so':
dlopen(/Users/oguz/.local/share/nvim/rocks/lib/lua/5.1/toml_edit.so, 6): no suitable image found. Did find:
/Users/oguz/.local/share/nvim/rocks/lib/lua/5.1/toml_edit.so: mach-o, but wrong architecture
/Users/oguz/.local/share/nvim/rocks/lib/lua/5.1/toml_edit.so: mach-o, but wrong architecture
stack traceback:
[C]: in function 'require'
...ocal/share/nvim/rocks/share/lua/5.1/rocks/operations.lua:115: in function 'parse_rocks_toml'
...ocal/share/nvim/rocks/share/lua/5.1/rocks/operations.lua:524: in function <...ocal/share/nvim/rocks/share/lua/5.1/rocks/operations.lua:509>
stack traceback:
[C]: in function 'error'
...oguz/.local/share/nvim/rocks/share/lua/5.1/nio/tasks.lua:95: in function 'close_task'
...oguz/.local/share/nvim/rocks/share/lua/5.1/nio/tasks.lua:117: in function 'step'
...oguz/.local/share/nvim/rocks/share/lua/5.1/nio/tasks.lua:145: in function 'run'
...ocal/share/nvim/rocks/share/lua/5.1/rocks/operations.lua:509: in function 'update'
....local/share/nvim/rocks/share/lua/5.1/rocks/commands.lua:98: in function 'impl'
....local/share/nvim/rocks/share/lua/5.1/rocks/commands.lua:181: in function <....local/share/nvim/rocks/share/lua/5.1/rocks/commands.lua:172>

Rocks update ->

Error executing vim.schedule lua callback: ...ihou/.local/share/nvim/rocks/share/lua/5.1/nio/tasks.lua:95: Async task failed without callback: The 
coroutine failed with this message:                                                                                                                
...ocal/share/nvim/rocks/share/lua/5.1/rocks/operations.lua:493: attempt to index local 'ret' (a number value)                                     
stack traceback:                                                                                                                                   
        ...ocal/share/nvim/rocks/share/lua/5.1/rocks/operations.lua: in function <...ocal/share/nvim/rocks/share/lua/5.1/rocks/operations.lua:454> 
stack traceback:                                                                                                                                   
        [C]: in function 'error'                                                                                                                   
        ...ihou/.local/share/nvim/rocks/share/lua/5.1/nio/tasks.lua:95: in function 'close_task'                                                   
        ...ihou/.local/share/nvim/rocks/share/lua/5.1/nio/tasks.lua:117: in function 'cb'                                                          
        ...ihou/.local/share/nvim/rocks/share/lua/5.1/nio/tasks.lua:183: in function <...ihou/.local/share/nvim/rocks/share/lua/5.1/nio/tasks.lua:1
82>

This happens with all the rocks-git managed packages commented out, so it should be a rocks.nvim issue.

Any thoughts?

Sorry guys for spamming issues. This one is nothing special. The word false seemingly disappears from the 2nd option's window in insert mode because of the wrapping (same thing if the user wants to provide a path longer than 50 characters in the 1st option).

Just a rough idea...

• Extends the Rocks command with
  • A request <owner>/<repo> subcommand that searches existing GitHub issues, and if not found, opens an issue requesting for the plugin to be published to luarocks (based on a template)
  • A pr <owner>/<repo> subcommand that searches PRs, and if not found, opens a luarocks-tag-release PR based on a template.

I was considering adding this feature as part of rocks.nvim core, but now that I have considered it I feel like it would make more sense to have as an external module.

This module would allow developers to test local, development versions of their plugin without having to push their code to a dev target on luarocks.org.

Idea for syntax:

[plugins.neorg]
dir = "~/dev/neorg/"

# or ...

[plugins]
neorg = { dir = "~/dev/neorg" }

When specified like this the version parameter would simply be ignored. :Rocks sync would not affect these entries. Any plugin that is specified with dir would simply be manually added by rocks-dev to the runtimepath.

The default (expected) way to handle plugins within one's configuration is to place plugins in a plugins/ RTP directory and check for the existence of the plugin with pcall.

A rocks-config module would allow users to specify per-plugin configuration files (if the plugin is installed and loaded). A global option could also be set which would specify the default directory where files for plugins would be sourced, e.g.:

[plugins]
# plugins go here...

[config]
path = "plugins/" # search in `$CONFIG_DIR/lua/plugins/xyz.lua` for each installed plugin

Root Cause

When attempting to figure out dependencies of rocks, rocks.nvim looks through all rocks from the rocks.toml file. The issue is, however, that it's not guaranteed that the rocks from rocks.toml are installed.

Solution

rocks.nvim should pull from state.installed_rocks() instead to resolve this issue.