feat: support extending the default luarocks config

[mrcjkb]

Stacked on #442

This adds a solution for #443 by making it easier to defend the default luarocks config.

You can add extra directories to search for binaries via

vim.g.rocks_nvim = {
  -- ...
  ---@type string | table file path or config table to extend the default with
  luarocks_config = {
    external_deps_dirs = { "/some/path" },
  },
}

See https://github.com/luarocks/luarocks/wiki/Config-file-format for details.

[github-actions]

Review Checklist

Does this PR follow the Contribution Guidelines? Following is a partial checklist:

Proper conventional commit scoping:

• For example, fix(installer): some installer bugfix

• Pull request title has the appropriate conventional commit prefix.

If applicable:

• Tested
  • Tests have been added.
  • Tested manually (steps in PR description).
• Updated documentation.

[teto]

unrelated to this PR but I noticed some redundancy between lua/rocks/config/init.lua and lua/rocks/config/internal.lua RocksOpts and RocksConfig : aren't these the same ? can we do something about the doc redundancy ?

[mrcjkb]

unrelated to this PR but I noticed some redundancy between lua/rocks/config/init.lua and lua/rocks/config/internal.lua RocksOpts and RocksConfig : aren't these the same ? can we do something about the doc redundancy ?

config/init and RocksOpts are exposed to the user. Each field of RocksOpts is optional (can be nil), allowing users to omit fields without getting lua-language-server warning diagnostics.

config/internal and RocksConfig are not exposed to the user. None of the fields of RocksConfig are optional, giving us better type safety.

It's a bit of boilerplate, but worth it imo.

[mrcjkb]

I've made writing/loading the luarocks config async + on demand. That ought to minimise the impact on startup time.
Also, if we need to update the config at runtime (maybe for parallel installs?), this is the better approach.

[teto]

I dont know what to think here. The luarocks_config as a string/table makes things more complex to understand.

If it's a string, then we just load the file without merging.
If it's a table, then we merge and write the file (but can't decide the location anymore).

Also it's user-facing so if it ends being a bad idea, it's hard to rewind.

One of the problems is that our luarocks config depends on vim.g.rocks_nvim.rocks_path, that seems like the only reason for merging the configs. We could mention that the first rock_tree is where to install stuff ? but that might be too complex for users.

If I take the nix scenario, I can generate the variables/rockspecs and pass it as vim.g.rocks_nvim.luarocks_config table. Right now, I had to copy the defaults from rocks.nvim into my generated luarocks config file so in that regards, the PR improves things.

[mrcjkb]

If it's a string, then we just load the file without merging.
If it's a table, then we merge and write the file (but can't decide the location anymore).

The string is to prevent this from being a breaking change.
If we decide we don't want to support it anymore, we can start off with a vim.deprecate and then remove support for it being a string in version 3.

Edit: Added a deprecation notice as discussed.

[mrcjkb]

How on earth did the integration tests get flaky again after a rebase?

[mrcjkb]

Merging, as tests are succeeding and all issues have been addressed.