nickmyatt commented on PR #41513: URL: https://github.com/apache/airflow/pull/41513#issuecomment-2297213033
Here's an example of the use of the `@dag` decorator with kwargs: https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/dags.html#the-dag-decorator That page says > As well as being a new way of making DAGs cleanly, the decorator also sets up any parameters you have in your function as DAG parameters, letting you [set those parameters when triggering the DAG](https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/dag-run.html#dagrun-parameters). You can then access the parameters from Python code, or from {{ context.params }} inside a [Jinja template](https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/operators.html#concepts-jinja-templating). So, it looks like the _intention_ is for these kwargs to be treated in the same way as the `params` argument to the `DAG` constructor, which _does_ accept `Param`s for richer trigger form definitions, as described here https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/params.html#use-params-to-provide-a-trigger-ui-form It would seem strange that `@dag` is _deliberately_ less powerful than `DAG` in this regard. -- 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. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
