Do you think we should start with some design doc for that? In this way, we can work out the best solution and allow other to add 2 cents?
T. On Tue, Feb 4, 2020 at 8:37 PM Daniel Imberman <daniel.imber...@gmail.com> wrote: > > 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. -- Tomasz Urbaszek Polidea | Software Engineer M: +48 505 628 493 E: tomasz.urbas...@polidea.com Unique Tech Check out our projects!
