[Feature] smarter `auto_setup`

[mrcjkb]

The auto_setup option, if enabled, could be dangerous, for the following reason:

• Calling require on a plugins's main module could lead to initialising things prematurely (e.g. in plugins that don't use a setup function for configuration, but instead load configs from a vim.g. table as soon as they are required).

A rather straightforward way to check if a plugin works without a setup call could be to search the runtimepath for

• <plugin-name>/plugin
• <plugin-name>/ftdetect
• <plugin-name>/ftplugin,
• ...

If one of those rtp directories is found, then it's very likely the plugin just works, and doesn't need a setup call.

As an extra safeguard, we could add a [plugins.plugin.nosetup] flag to rocks.toml.

[augustocdias]

It would be nice to be able to configure the auto_setup per plugin instead of all or nothing.

[pedrohgmacedo]

It would be nice to be able to configure the auto_setup per plugin instead of all or nothing.

Just support LazySpec instead.

[mrcjkb]

It would be nice to be able to configure the auto_setup per plugin instead of all or nothing.

Just support LazySpec instead.

See my response to the issue :smile:

[pedrohgmacedo]

See my response to the issue 😄

I asked there:

What thing is rocks.nvim doing well?

[augustocdias]

@pedrohgmacedo just use lazy then. there's nothing wrong with it. in fact it is great. rocks follows a different approach and if it is not what you're looking for, its fine. I don't think anyone here is trying to satisfy every user and every use case.

The approach from rocks is different from all the other alternatives and so the way it works. You don't have to like it but you also don't have to start toxic discussions questioning if it's good or bad either.

I personally haven't migrated from lazy, but I think I will in the near future as I find this approach more elegant and easier to maintain.

[pedrohgmacedo]

Not trying to troll or anything here, really, I just honestly did not understand the use of this.

[augustocdias]

Not trying to troll or anything here, really, I just honestly did not understand the use of this.

For me the biggest appeal of Rocks would be better dependency management between plugins. Think of plugins that depend on nui or dressing for example. They could just specify in the rocks spec that they depend on it and the end user wouldn't have to manually set to download this plugin. Many plugin maintainers copy the code from other repos to avoid that, which is also not a good approach.

Other good benefits is having a server for all packages instead of downloading them directly from git repos and better versioning control from the user and author.

[pedrohgmacedo]

Many plugin maintainers copy the code from other repos to avoid that, which is also not a good approach.

You'll only get these benefits if plugin maintainers adopt rocks.

[mrcjkb]

Many plugin maintainers copy the code from other repos to avoid that, which is also not a good approach.

You'll only get these benefits if plugin maintainers adopt rocks.

For plugins whose maintainers don't adopt rocks, we have the Neovim User Rock Repository [NURR].

[flexagoon]

It would be nice to be able to configure the auto_setup per plugin instead of all or nothing.

@augustocdias for now you can just add en empty config block, eg

[plugins.foobar.config]

Will just call require("foobar").setup() with no options

[bottd]

A hack to disable setup for specific plugins with auto_setup is creating a no-setup bundle:

[bundles.no-setup]
items = [
  "nvim-web-devicons"
]

Then create an empty lua file named plugins/no-setup.lua. This will load an empty file to "set up" the listed plugins

[TarunDaCoder]

It would be nice to be able to configure the auto_setup per plugin instead of all or nothing.

Or maybe something like this

[plugins.auto_setup]
plugins = [
    "foobar.nvim",
    "etc.",
]

[mrcjkb]

It would be nice to be able to configure the auto_setup per plugin instead of all or nothing.

Or maybe something like this

[plugins.auto_setup]
plugins = [
  "foobar.nvim",
  "etc.",
]

This would add a source of truth to the config. I think the simplest option is to allow for the config field to be a boolean that overrides auto_setup per plugin. It's not ideal that the config field is now a union type, but it's the only solution I can think of that doesn't involve multiple sources of truth. And since the auto setup feature is a hack anyway, I don't feel too strongly about it. But I'll await an approval from @vhyrro.

[TarunDaCoder]

I think the simplest option is to allow for the config field to be a boolean that overrides auto_setup per plugin.

This would actually be quite amazing!