Replies: 1 comment 6 replies
-
I don't entirely understand the problem. Do you mean that it's hard to exclude built-in plugins? Or are we trying to make it easier to include additional plugins? Or is it updating built-in plugins themselves? Essentially, I'm not sure what "pull in new Conduit changes" means and what we're improving. |
Beta Was this translation helpful? Give feedback.
6 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
The problem
Currently, to include additional built-in plugins into a custom Conduit build, the source code needs to be changed. That makes it more complicated to pull in new Conduit changes (revert changes to the list of built-in connector, pull new Conduit changes, add new built-in connectors again, build Conduit).
The 'why'
Built-in plugins are faster than standalone plugins, so there's a strong motivation to include a plugin in Conduit's binary. I'm also assuming that the connectors used for a specific Conduit instance are not going to change that frequently. In those cases, where the connectors used are all/most of the time the same, it makes sense to have a custom build with those connectors as built-in plugins.
An example
The list of built-in plugins can be made "external", i.e. in a separate file and then included during the build process, for example:
Then, something like
make build-with-plugins /path/to/plugins.go
would build Conduit with conduit-connector-foo as a built-in plugin.For now, I think this discussion can focus on the usefulness of such a feature. If we agree that having it is useful, we can discuss the implementation.
Beta Was this translation helpful? Give feedback.
All reactions