vemikhaylov commented on PR #29608:
URL: https://github.com/apache/airflow/pull/29608#issuecomment-1442592589
> `--xcoms`
I love it! Though technically the "task" declaration operates with the
`XComArg` layer, inside the task execution it may call `xcom_pull` and
`xcom_push` directly, which is about pure `XCom`, so it may be fine and even
more precise to go laconic.
> ```
> airflow task run ... \
> --xcom task1 key value \
> --xcom task2 k1 v1 \
> --xcom task2 k2 v2
> ```
>
> I think this is possible by setting `nargs=3`.
It looks really great! Though there are the following issues, which I see
with the format:
1. It's not rather extensible. Imagine we want to pass one more argument
(e.g., `map_index` - I'm not sure if it's applicable, but let's imagine it's).
Then it becomes `--xcom task1 key value map_index` - may be becomes less
intuitive interface, where you should remember the order of the arguments.
2. It's possible to introduce the default key (i.e., `return_value`) by
interpreting 2 args as `--xcom task1 value`, but it makes even harder to
extend it to more args in the future if needed.
3. It's not consistent with `--env-vars` and `--task-params`, which are JSON
already.
Please let me know if those are valid concerns. I personally prefer more
explicit interfaces and sometimes lean towards overly explicit ones, so it all
may be rather subjective, feel free to push back :)
But so far I would probably stick to:
```
--xcoms [{"task_id": "get_python_echo_message", "value": "test xcom arg"},
...]
```
and
```
--xcoms my_xcoms.json
```
In terms of execution, I wanted to ask if it's fine if I move iteratively
here and break it down into two PRs: 1) CLI value passing; 2) File value
passing? Among other things, it should facilitate the review process a bit. The
first part should be self-contained as well, so probably a safe change to be
committed separately?
--
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]
