On Wed, 2016-03-30 at 09:02 -0400, Martin Kolman wrote: > > ----- Original Message ----- > > > > From: "Chris Lumens" <clumens@xxxxxxxxxx> > > To: anaconda-devel-list@xxxxxxxxxx > > Sent: Wednesday, March 30, 2016 2:36:12 PM > > Subject: Re: Potential deprecation in RHEL 7.3 ADDON API > > > > > > > > This PR will cause that all existing addons to get deprecation > > > warning > > > message. This includes our OSCAP and KDUMP addons. > > > > > > The change is really small. You only need to change two lines of > > > code. > > > I'm going to create PR for our addons when this PR receive ACK. > > > > > > This change happens on master and it will be also in RHEL 7.3 . > > > I want to give you notification about this change before it > > > happens by > > > this mail. If I missed something or you don't want this change > > > please > > > write comments to PR or reply to this mail. > > You can avoid having to deal with deprecation warnings and all that > > if > > you instead define execute to also take *args and **kwargs, and > > then > > pass payload to it as a kwarg everywhere. Addons that don't do > > that > > just won't have access to the payload, but that's their problem. > I think that the problem is that they might have overridden the > method in their addon, > so that when we call it with an unknown kwarg they will get an > exception. > > They might have something like this in their addon code: > > def execute(self, storage, ksdata, instclass, users): > > Even if we change the parent class method signature to: > > def execute(*args, **kwargs): > > The overridden method will still be called when we call execute with > payload=<payload instance> > and they will get: > > TypeError: execute() got an unexpected keyword argument 'payload' > > > I can see two more or less hacky ways of working around this without > breaking backward compatibility for > addons (which I assume should be maintained on RHEL, mainly due to > custom addons customers might have): > > 1) Catch the type error and retry without the payload kwarg: > > try: > ad.execute(foo, bar, baz, payload="ABC") > except TypeError: > ad.execute(foo, bar, baz) I tried this and trash it later. Problem here is that you also catch every TypeError in the code of the addon. For example calling list as a method. Workaround for this could be to test what is written in exception but it is uglier and less stable than actual solution. > > 2) Use the inspect module to check if the method expects the payload > kwarg (or **kwargs) > and only call it with it if it does. Note that this is ultra-bleh- > hacky and probably > also pretty un-Pythonic. I think so too and from point of view I have now. It's better to have actual solution. Jirka > > > > > > > - Chris > > > > _______________________________________________ > > Anaconda-devel-list mailing list > > Anaconda-devel-list@xxxxxxxxxx > > https://www.redhat.com/mailman/listinfo/anaconda-devel-list > > > _______________________________________________ > Anaconda-devel-list mailing list > Anaconda-devel-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/anaconda-devel-list _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
