[GitHub] [airflow] potiuk edited a comment on issue #15198: "cannot import make_kwargs_callable" occurs when using airflow.providers.http.operators.http in 1.10.14.

[GitBox <gi...@apache.org>]

potiuk edited a comment on issue #15198:
URL: https://github.com/apache/airflow/issues/15198#issuecomment-813909054


   While we don't officially release the backports and as @mik-laj mentioned it is quite an overhead to release one. 
   
   However we have to take into account that the Http provider is one that is very commonly used, so we might try to think about doing a one time release to fix it as it might be a recurring problem for other users. 
   
   This is an exceptional case - it is not a but to fix but our own backwards incompatibility introduced in November. The reason for the problem was that - unfortunately the `make_kwargs_callable` was implemented  via local imports, thus bypassing the protection we added to catch this kind of problem in #11922 and it slipped under the radar of reviews. I can imagine few ways how it can be "quickly" implemented in an out-of-bands release for just http backport provider - without a lot of overhead. Happy to do it actually.
   
   There are two things to do - one tactical for now for you and more strategic what we do for the provider,
   
   1) For the tactical part - in the meantime @kurtqq and @odajun and @alexInhert there are two mitigations:
   
   a) you can simply stay with the old import when testing migration. It **should** work as long as you do not make use of the `make_kwargs_callable` so far. 
   b) You can install `apache-airflow-backports-provider-http==2020.10.5` - it has no offending code, and it should work fine. There were mostly refactorings/standardizations/documentation changes since then in HTTP provider. So it should **just work**. 
   
   2) I think It will be rather easy to move the "make_kwargs_callable" to inside the http backport provider (this is only problem with http provider it seems) and release an out-of-band backport provider, creating a branch for it branching off the `legacy-backport-cutoff-point`. I think the biggest overhead there is not doing the changes but testing it. And here is my ask @odajun @kurtqq  @alexInhert  - if I release it later today or tomorrow as RC - would you volunteer to test it and report it back please ? That could help a lot with our decision of releasing it.
   
   Another option for strategic solution is simply to yank the releases after 2020.10.5  and leave only that version. Not nicest, but I think it should work and have no side effects.
   
   @mik-laj @kaxil @ashb  WDYT? 
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org