search

nvim-neorocks / rocks-dev.nvim

A swiss-army knife for testing and developing rocks.nvim modules.
GNU General Public License v3.0
15 stars 3 forks source link

Rocks-dev loaded after rocks-config breaks configurations #15

Closed danymat closed 5 months ago

danymat commented 5 months ago

Hello,

It seems to be quite related to #8 (because of plugin init order). The issue here arises when you install rocks-config and rocks-dev, and use a configuration in lua/plugins/<plugin>.lua for a plugin that is installed by rocks-dev.

For example, install neogen locally with rocks-dev:

[plugins]
# Rocks ones
"rocks.nvim" = "2.27.1"
"rocks-config.nvim" = "1.5.0"
"rocks-dev.nvim" = "1.2.1"

[plugins.neogen]
dir = "~/Developer/neogen"

Create a configuration file in lua/plugins/neogen.lua and restart neovim. Running :checkhealth rocks-config will say that neogen module was not found. But the neogen module is loaded (without it's configuration). Checking with :lua vim.print(require("neogen")) works.

My guess is that rocks-config, because of its preload script, will load before anything else, and check for modules installed with default rocks.toml behavior. It will find neogen in the toml, try to execute the confuguration file, but if you require the plugin, it will error out because the plugin will be loaded after, when rocks-dev will be loaded.

My guess would be to load rocks-dev plugins before, or check with rocks-config if rocks-dev is installed and has plugins installed. For a workaround fix, I used:

vim.cmd([[packadd rocks-dev.nvim]])

At the end of my init.lua file, that will load rocks-dev.nvim before anything (even before rocks-config). But i guess this is just a temporary solution

mrcjkb commented 5 months ago

Hey 👋

This would indeed likely be solved by the solution for #8.

The issue is that dev plugins are neither luarocks packages, nor are they on the packpath.

I think your workaround is a pretty good solution, actually. If you install rocks-dev change it to vim.cmd.packadd { 'rocks-dev.nvim', bang = true }, it should add the plugin to the runtimepath without sourcing the plugin script (I'm not sure, but you might have to set opt = true for rocks-dev. As a result, the dev plugins' scripts would still be sourced after rocks-config.

I'll close this as a duplicate of #8.