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 bug 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:
[email protected]


Reply via email to