You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@airflow.apache.org by "potiuk (via GitHub)" <gi...@apache.org> on 2023/08/16 06:54:08 UTC

[GitHub] [airflow] potiuk commented on a diff in pull request #33423: Add a mechanism to warn if executors override existing CLI commands

potiuk commented on code in PR #33423:
URL: https://github.com/apache/airflow/pull/33423#discussion_r1295454820


##########
airflow/cli/cli_parser.py:
##########


Review Comment:
   I am very strong for just hard-failing it. 
   
   If the one who develops executor wants to have a new command, then .... let it be new command. Having the same command will be extremely confusing for the users. Will it have 100% compatibility when it is used? Which documentation they should look at ? What if there are subtle differences in behaviours? What if there is a new version of the original command released with new option that is missing in the new command?
   
   All those questions need answering and defining the expected behaviour  and communicating that to our users if we allow to override the command.
   
   All those questions do NOT need answering, documentation, protection etc. if we fail hard. At the expense of having two similar commands. But logically speaking we WILL have two similar commands. They will never be exactly the same, almost by definition they will differ - if only by the sheer fact that somone can use different versions of provider with the same version of airflow and commands contributed by that different versions of providers will - inevitably- be different. And the user should be aware of that. 



-- 
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: commits-unsubscribe@airflow.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org