[WIP] Load Vmdb::Plugins via bundler #15461
Conversation
Takes the existing mechanism for determining Vmdb::Plugins, and moves the logic into it's own class with a interface that can be repeated with other Registry providers (working title...) This can allow other things to provide the plugin registry, like bundler, or a yaml config instead of relying on Rails to do that for us. This doesn't remove the concept of using Rails engines to additional components to our routes and such, but removes it from being a dependency for defining plugins in the manageiq application.
Uses Bundler as the source for determining vmdb plugins to be loaded.
NickLaMuro
force-pushed
the
load_vmdb_plugins_via_bundler
branch
from
2524a5c
to
5c36ea1
Compare
|
Checked commits NickLaMuro/manageiq@383eb13~...5c36ea1 with ruby 2.2.6, rubocop 0.47.1, and haml-lint 0.20.0 |
| end | ||
|
|
||
| def plugin_gems | ||
| ::Bundler.locked_gems.specs.select do |spec| |
There was a problem hiding this comment.
Sorry, dumb question... Is this the main or only place we're talking to Bundler? I guess I was expecting more based on the namespacing and PR title. I want to make sure I'm not missing something.
There was a problem hiding this comment.
@jrafanie Yes, and this is also only used in fetch_plugins.
Sidenote: I originally appended the map {|spec| Plugin.new to the end of this block, and had all of it inside of the fetch_plugins method, but "rubocop didn't like that" (he says in a whiney sarcastic voice).
The reason I mention that this was originally in fetch_plugins is because Vmdb::Plugins::Registry::Rails.fetch_plugins is also the only place that Rails.application is ever accessed as well in it's respective class. The only difference is that the engine interface exposes root and name directly, which is what we end up using to build the plugin map, but a "proxy interface", aka Vmdb::Plugins::Registry::Bundler::Plugin class above, was needed to allow that same interface to exist for the bundler one.
|
So I think similar to what I said in my recent comment in #15336 is valid here, and whether or not this should be closed should be determined by the result of that. That said, I think the |
|
This pull request is not mergeable. Please rebase and repush. |
|
Closing this in favor of #17643 since that seems to be about read to be merged. Honestly, was just waiting for this to hit the 1 year mark before I closed it. Totes serious, mmkay. ... ... ...
|
Creates a registry interface for loading
Vmdb::Plugins, adds not only the existing Rails Engine mechanism as one of the registry adapters (still the default), but includes an additional registry interface for loading via Bundler.This also lays the groundwork for a more verbose plugin registry system that is "pluggable", and hopefully less dependent on needing "all the things" to run. This is in no way implemented in this PR, but will hopefully help facilitate that in the future™.
Steps for Testing/QA
Ideally this is a low risk PR, so nothing should change by default with these changes.