----- Original Message ----- > From: "Dominic Cleal" <domi...@cleal.org> > To: foreman-dev@googlegroups.com > Sent: Tuesday, November 8, 2016 5:42:04 AM > Subject: Re: Creating a plugin-for-tests (was [foreman-dev] Plugin test > failures) > > On 07/11/16 15:39, Stephen Benjamin wrote: > > The wiki says that public methods will be deprecated and given a chance > > to adjust our code in a reasonable time where possible: > > > > "Foreman will always strive to make no incompatible changes in a minor > > release, but be prepared > > to make updates on major releases. Where possible, deprecation warnings > > will be added for old > > public methods before their removal. Warnings will be issued for two > > major releases and then the > > old method removed in the third release, giving plenty of time to > > update plugins." > > > > I read that as being quasi-official to be able to do alias_method_chain on > > public methods > > No, this means public methods should still be able to be called, not > redefined. There's no mention of support for redefining methods via > alias_method_chain (or others) in the plugin documentation. > > There's little Foreman can do if a method is being redefined and is > later deprecated in favour of something else, since Foreman would no > longer call the deprecated method. The deprecation is only useful when > it's called, not modified. > > > but very often - nearly always - they are not deprecated and > > the signature just changes or maybe the method is even removed. It > > constantly breaks > > my plugin. > > Be more defensive against signature changes by redefining the method > with a splat operator, e.g. def foo(*args) and passing *args to the > original method. If arguments with defaults are added, no change is > required to the redefined method. > > > And the plugin API (which itself is a mess given it grows organically and > > ad hoc instead > > of some team spending time to get it right) is pretty limited if you want > > to add on to Foreman objects. > > Please expand it then, or at least ensure a ticket is filed in the > Plugins category in Foreman's issue tracker for the functionality you > require. > > It's good that it's ad-hoc because those are the extensions points that > plugin authors have needed, and they can be specifically tested.
I strongly disagree with this. One thing we see now is as they get added organically, every single one works in a different way and stores the plugin configuration in a different way, often resulting in bugs. Just look at this and the attached bugs: http://projects.theforeman.org/issues/12747 We don't only add API calls whenever a need to use it comes up, likewise obviously important objects should have plugin extension points. I suggested adding a representative plugin to the test matrix so users were aware that particular methods are used by plugins and maybe find a way to avoid changing it, at least until the plugin extension points are better. There is definitely a common set of things that people are alias_method_chaining or hooking onto to add objects to host groups, hosts, title bar actions, etc. But the answer from this thread is basically, "too bad." So I'm just going to stop trying to plug the holes in the drowning ship that is foreman_salt. - Stephen > -- > Dominic Cleal > domi...@cleal.org > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
