How best to allow external modules to interact directly with config imports

[simifalaye]

Use Case

Now that support for configuration imports has been implemented, I'd like to move towards one of the other goals I had with configuration modularization. I use the rocks-treesitter module with the auto_install option to automatically install treesitter parsers when I come across a matching filetype. My config is deployed on different systems, one for work and one for personal development, so I will work on different languages on each machine. When they are all in my base configuration, it means that I will have treesitter parsers installed on one machine that I will never use on that machine. Thus, I'd like to pull all of the tree-sitter parsers out of my main rocks.toml file that is committed to my git repo into a separate local-only rocks-treesitter.toml file. I'd like an option in rocks-treesitter that when enabled, it will automatically install and maintain the treesitter parsers in this local toml file only and not use my main rocks.toml at all. I could manage this myself by moving the treesitter plugins to the local file each time a new one is installed but this would be cumbersome, especially given that it could be automated since rocks-treesitter is already automatically installing parsers for me.

Issue

Since we've abstracted the fact that there are potentially multiple config files away from external modules then there wouldn't be any way that rocks-treesitter could simply just setup an install hook to install treesitter parsers into a separate file and add an import table to the base configuration file.

Solutions

Register install rules

This would allow external modules to register installation rules where you would specify rocks/plugin names or regexes (in the rocks-tressitter case, it could register tree-sitter-*) and a config path string relative to the base config file. When doing an install, rocks.nvim would see if the rock/plugin name matches with any of the registered install rules, if so, it would create the import table in the base config if it doesn't exist, add the config path to the import table, create the import config file and add the rock/plugin data to that toml file.

Allow external modules to interact with the config tables directly

This could either be through adding more handler function options which would pass in a list of MutRocksTomlRef for each config instead of a single one. Or it could be with a separate API function that gives you access to the individual config tables.

Any other ideas?

[simifalaye]

@mrcjkb

[mrcjkb]

That's an interesting problem.
I think the solution could be simpler than that for now.

rocks-treesitter uses rocks.api.install.
We could potentially extend that function's signature to take a table of options, one of which would be the config file to write to.