You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It feels unfamiliar to have to specify each package effectively twice: once to declare it as a plugin and once to use it.
It would feel more natural if you could specify a plugin registry (as a plugin itself maybe, or as a setting), and then the packages.
Option 1
This option assumes there is a toml-registry-plugin, probably implemented in Wasm. You can instantiate the plugin multiple times, and configure the plugin, and use the plugin name as a prefix when referencing packages.
This is probably unnecessarily complex and confusing.
Option 2
In this example, if proto can't find any of the listed packages in its own set of built-ins, then it consults the toml-fallback-path setting to see if the package is listed there.
This is probably the simplest to implement, since no plugin needs to be added.
Option 3
This option assumes that, just like go, a built-in plugin exists (maybe source:https://github.com/moonrepo/toml-registry-plugin/releases/download/vX.Y.Z/toml_registry_plugin.wasm) that gets activated if a certain file exists, e.g. .prototools.registry. That file could specify where to find the toml plugin files. The plugin could also get activated if there is a relevant setting configured (e.g. tools.registry).
This seems like a clean way to introduce and use this feature, however, I'm not sure if the current plugin infrastructure allows for a plugin with this kind of functionality. This would probably require changes to plugin capabilities and hooks inside proto itself. Seems a bit complex, and I'm not sure if the payoff is worth it.
The text was updated successfully, but these errors were encountered:
A plugin registry is on the roadmap but it will be a while before it lands.
I do agree though that adding 2 entries for each plugin is kind of a lot. I typically add the [plugins] entries to the global config, and then the versions to the local configs. That at least cleans it up a bit.
W1M0R
changed the title
Feature request: plugin registry
Feature request: local plugin registry
Jul 25, 2024
Thanks for the tip! It does clean it up a bit, and it's not that much additional effort. I add the plugins to the root of my monorepo, and then let subprojects use the packages and set the versions.
This is my
.prototools
at the moment:It feels unfamiliar to have to specify each package effectively twice: once to declare it as a plugin and once to use it.
It would feel more natural if you could specify a plugin registry (as a plugin itself maybe, or as a setting), and then the packages.
Option 1
This option assumes there is a
toml-registry-plugin
, probably implemented in Wasm. You can instantiate the plugin multiple times, and configure the plugin, and use the plugin name as a prefix when referencing packages.This is probably unnecessarily complex and confusing.
Option 2
In this example, if proto can't find any of the listed packages in its own set of built-ins, then it consults the
toml-fallback-path
setting to see if the package is listed there.This is probably the simplest to implement, since no plugin needs to be added.
Option 3
This option assumes that, just like go, a built-in plugin exists (maybe
source:https://github.com/moonrepo/toml-registry-plugin/releases/download/vX.Y.Z/toml_registry_plugin.wasm
) that gets activated if a certain file exists, e.g..prototools.registry
. That file could specify where to find the toml plugin files. The plugin could also get activated if there is a relevant setting configured (e.g.tools.registry
).This seems like a clean way to introduce and use this feature, however, I'm not sure if the current plugin infrastructure allows for a plugin with this kind of functionality. This would probably require changes to plugin capabilities and hooks inside proto itself. Seems a bit complex, and I'm not sure if the payoff is worth it.
The text was updated successfully, but these errors were encountered: