I think if we’re not breaking any other operators (which I doubt we are) it’s a great 2.0 feature. It would also look great in a “What’s New in Airflow 2.0” announcement ;).
Docs are always a challenge, but we could set up a google doc and hack it out in a day or two. +1 via Newton Mail [https://cloudmagic.com/k/d/mailapp?ct=dx&cv=10.0.32&pv=10.14.6&source=email_footer_2] On Tue, Feb 4, 2020 at 2:29 AM, Jarek Potiuk <jarek.pot...@polidea.com> wrote: I like the idea, especially the backwards compatibility. I would love to understand more about whether it will work (it looks like it will) without modifying the 100s of operators we already have. If so, this looks like a nice addition to the current way how we define Dags and even allows for incremental migration from the "traditional" to "functional" Dag definition pattern. It does not enforce it but it opens up new possibilities without changing basic paradigms of Airflow. It looks like we could even make it available in 2.0 as there are hardly any dependencies and very low risk with introducing such change. I think the biggest challenge will be to write good documentation and making sure that examples are there - but maybe we could even somewhat automate it and generate some part of the "functional variants" for the examples we have? WDYT Dan, others ? J.
