+1 for this change! I especially had lots of trouble with template files with templated filenames and this would solve it.
Few comments/questions: "improved debuggability when things go wrong": Could you elaborate on how this proposal improves debuggability? "better discoverability of whether a field is template-able”: Would be good to mention that this proposal defines template-ability on argument-level instead of (currently) attribute-level It appears that a code author would still have to read an operator’s source code to understand which arguments are template-able. How does this proposal improve discoverability? Have you considered implementing template classes for other native types e.g. BoolTemplate or IntTemplate, or do you intend to use render_template_as_native_obj for that? Bas > On 16 Jul 2024, at 04:09, Tzu-ping Chung <t...@astronomer.io.INVALID> wrote: > > Hi all, > > Following previous discussions in Airflow 3 Dev Calls, I’m proposing a new > templating syntax for Airflow 3 to replace the current field-templating > behaviour. Link to document is attached below. While this is a big breaking > change in DAG syntax, I feel the benefits are significant enough to attempt > for the major version bump. > > I want to also use this opportunity to raise a couple of issues related to > this, and some other proposed changes: > > 1. Possibility of a transitional 2.11 to “back-port” some syntaxes backwards > so users can use them before they upgrade. > 2. A separate “airflow_compat” package to allow users to minimally change the > code before upgrading to Airflow 3 to receive the new behaviour, and change > the DAG syntax later. > > The new ideas do not depend on each other; they are means to a similar goal > approached from different directions. > > I’m interested to hearing any thoughts on this. > > TP > > > https://docs.google.com/document/d/1R4uSF0MGWifKrWk_pzjDcaYtgwtmJo9q7wg1iFiFKO4/edit?usp=sharing
