-
Notifications
You must be signed in to change notification settings - Fork 3
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
Language agnostic plugins #58
Comments
To support agnostic plugins would Docker be a suitable solution? it would allow for a simpler loading operation as we won't have to reason about the plugins runtime. There are a few ways we could enable rpc communication to the containers such that we can keep similar interfaces to what is currently implemented. |
I honestly think this is not a high priority at all. I would prefer to keep it Go-only maybe extending it to one more language (TypeScript?). Otherwise, it will get out of hand quickly. |
Docker has never been a requirement to run Ignite and I really hope we keep it that way. |
The fact that we would allow plugins to be written in other languages might help and ease some integrations with the CLI which are already developed using other languages. Atomkraft would be good example as it is written in Python. I want to mention that if and when this support is implemented I would be happy write the Python code required to facilitate integration, unofficially if needed. |
Apps support gRPC since ignite/cli#3529 so the CLI is able to interact with plugins written in other languages. The next step is to support launching plugins written in other languages because right now they are expected to be written in Go. I'm creating a new issue for it. |
Currently, a plugin must be written in go. Since the plugin system is based on a client-server stack, we can make it language agnostic.
To do that we need 2 changes in the plugin system:
change the network encoding: currently it's gob, which is only known by the go language. We have to switch to GRPC (I mentionned JSONRpc but I was wrong), as it is supported by the plugin library (see https://github.com/hashicorp/go-plugin/tree/master/examples/grpc)
find a way to describe how a plugin should be compiled and/or run. Currently the plugin system assumes the plugin is written in go, so it builds it using
go build
and then run the binary. We might need a manifest file that describes how to deal with a plugin written in an other language. If no manifest is found, we assume the plugin is written in go.The text was updated successfully, but these errors were encountered: