bugraoz93 commented on issue #45661: URL: https://github.com/apache/airflow/issues/45661#issuecomment-2781450179
> [@bugraoz93](https://github.com/bugraoz93) While developing `dags` commands, server commands may share arguments (dag_id, output, verbose, etc.) It seems to cause conflicts and complications when PRs are merged. Would it be better to write the arguments that are common to commands under `#shared` and resolve conflicts in the order in which PRs are merged? ([like this](https://github.com/bugraoz93/airflow/blob/4d679845d712c6a291e53e67847bf3e3838f5272/airflow/cli/cli_config.py#L144)) What do you mean by `server commands`? If you mean something like `dag-processor`. Those won't be available in `airflowctl`. Most shared ARGs are used more on `dags` and `tasks`. We won't transition any `tasks` commands yet either at the first iteration. The first plan was in the airflow-core which then flatten into commands. This could be a good baseline. What has been reverted under remote commands in the combination for further granular split. These are now aiming to be in `airflowctl` :) https://github.com/apache/airflow/pull/48224 https://github.com/apache/airflow/pull/47538 I believe that for ARGs and or a PR merged in `cli_config.py`, there should be a one-time conflict for all downstream PRs when the ARG is added. Even though we added the ARGs first, this is inevitable. I am okay with merging the ARGs early on, but that won't be enough for conflicts. If we put them in order with comments, that could potentially ease the rebase process. -- 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]
