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
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
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