casassg commented on issue #8052: URL: https://github.com/apache/airflow/issues/8052#issuecomment-619485205
Regarding templating, I understand why you say that now. An option we implemented internally to do this was to add a `map` function to XComArg which is lazy evaluated and that enables transforming the value pulled before passing it to the operator. My main worry is enabling the Jinja string is that it may cause some non-expected behaviour. For example, what happens when the value is not a string? I rather not enable it mostly because it still can be done using `context['ti'].xcom_pull` if users needed, while not causing errors for users that are just starting to use Airflow. Regarding BaseArg class. I would say no as we are moving the extensibility piece to XCom itself. That should allow to inject custom serialization/deserialization behaviour consistently across Airflow and not only XComArg. Can't think of any other reason to overwrite XComArg apart from custom serial/deserial logic. ---------------------------------------------------------------- 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: us...@infra.apache.org
