Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: local plugin registry #558

Open
W1M0R opened this issue Jul 24, 2024 · 2 comments
Open

Feature request: local plugin registry #558

W1M0R opened this issue Jul 24, 2024 · 2 comments

Comments

@W1M0R
Copy link

W1M0R commented Jul 24, 2024

This is my .prototools at the moment:

golangci-lint = "1.59.1"
gum = "0.14.1"
pixi = "0.25.0"
aqua = "2.30.0"
sttr = "0.2.22"
names = "0.14.0"
commitlint = "0.1.11"
bkt = "0.8.0"
fzf = "0.54.0"
watchexec = "2.0.0"

[plugins]
golangci-lint = "file://etc/proto/golangci-lint/plugin.toml"
pixi = "file://etc/proto/pixi/plugin.toml"
watchexec = "file://etc/proto/watchexec/plugin.toml"
sttr = "file://etc/proto/sttr/plugin.toml"
staticcheck = "file://etc/proto/staticcheck/plugin.toml"
templ = "file://etc/proto/templ/plugin.toml"
aqua = "file://etc/proto/aqua/plugin.toml"
gum = "file://etc/proto/gum/plugin.toml"
names = "file://etc/proto/names/plugin.toml"
goi18n = "file://etc/proto/goi18n/plugin.toml"
commitlint = "file://etc/proto/commitlint/plugin.toml"
bkt = "file://etc/proto/bkt/plugin.toml"
fzf = "file://etc/proto/fzf/plugin.toml"

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.

golangci-lint = "foo1://1.59.1"
gum = "foo1://0.14.1"
pixi = "foo1://0.25.0"
aqua = "foo1://2.30.0"
sttr = "foo1://0.2.22"
names = "foo1://0.14.0"
commitlint = "foo1://0.1.11"
bkt = "foo1://0.8.0"
fzf = "foo1://0.54.0"
watchexec = "foo2://2.0.0"

[plugins]
foo1 = "source:https://github.com/moonrepo/toml-registry-plugin/releases/download/vX.Y.Z/toml_registry_plugin.wasm"
foo2 = "source:https://github.com/moonrepo/toml-registry-plugin/releases/download/vX.Y.Z/toml_registry_plugin.wasm"

[tools.foo1]
path = "file://etc/proto"

[tools.foo2]
path = "https://github.com/Phault/proto-toml-plugins"

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.

golangci-lint = "1.59.1"
gum = "0.14.1"
pixi = "0.25.0"
aqua = "2.30.0"
sttr = "0.2.22"
names = "0.14.0"
commitlint = "0.1.11"
bkt = "0.8.0"
fzf = "0.54.0"

[settings]
toml-fallback-path = ["file://etc/proto", "https://github.com/Phault/proto-toml-plugins"]

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).

golangci-lint = "1.59.1"
gum = "0.14.1"
pixi = "0.25.0"
aqua = "2.30.0"
sttr = "0.2.22"
names = "0.14.0"
commitlint = "0.1.11"
bkt = "0.8.0"
fzf = "0.54.0"

[tools.registry]
paths = ["file://etc/proto", "https://github.com/Phault/proto-toml-plugins"]

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.

@milesj
Copy link
Contributor

milesj commented Jul 24, 2024

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 W1M0R changed the title Feature request: plugin registry Feature request: local plugin registry Jul 25, 2024
@W1M0R
Copy link
Author

W1M0R commented Jul 26, 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants