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

Dependencies of two different plugins can conflict #24

Open
hyfen opened this issue Mar 3, 2022 · 1 comment
Open

Dependencies of two different plugins can conflict #24

hyfen opened this issue Mar 3, 2022 · 1 comment
Labels
plugins Chronicle plugin system

Comments

@hyfen
Copy link
Member

hyfen commented Mar 3, 2022

Right now, plugins aren't dependencies of chronicle-etl and we just check for which chronicle-* gems are available at runtime and try to load them all. The problem is that plugins can have conflicting dependencies.

A typical scenario: for two platforms foo.com and bar.com, the ruby client libraries ruby-foo and ruby-bar will require different versions of faraday. If a user runs gem install chronicle-foo and gem install chronicle-bar and then tries to use them both within chronicle-etl, we'll get a Gem::ConflictError.

Possible solutions:

  • Make this project a monolith. We centralize plugins into the chronicle-etl repo and let bundler handle dependency resolution and accept that our bundle size will be huge and potentially hard to install if any plugins require native extensions.
  • Only allow one plugin to be used at the same time. Because we won't load all available plugins, the Connector Registry won't know which connectors are available (because the register_connector macro won't be called) so we'll need another technique
  • Adding commonly-used plugins as dependencies in chronicle-etl.gemspec and we can guarantee that at least those ones can run well together.

In any case, it'll be important to provide enough infrastructure in chronicle-etl so that plugins will need only a few additional dependencies.

@hyfen
Copy link
Member Author

hyfen commented Mar 4, 2022

Right now, the connector Registry needs a plugin to be loaded to learn which connectors are available (via the #register_connector macro called in connectors).

Instead, we could use a plugin's chronicle-PLUGIN.gemspec's metadata hash to list which connectors are available. Example: spec.metadata["extractor:history"] = "Shell command history".

The Registry could then populate itself by looking for these metadata keys in Gem::Specification.filter{|s| s.name.match(/^chronicle-/) }

Attempts to require a plugin (and its dependencies) would only happen at runtime when running a job that uses them and we'd only be using one (or a handful at most), thus reducing the potential for conflict.

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

No branches or pull requests

1 participant