chronicle-app / chronicle-etl

📜 A CLI toolkit for extracting and working with your digital history
https://chronicle.app/
MIT License
149 stars 3 forks source link

Dependencies of two different plugins can conflict #24

Open hyfen opened 2 years ago

hyfen commented 2 years ago

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:

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 commented 2 years ago

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.