Hey Buğra, Thanks for starting this thread.
Given the two approaches: 1. Positional only for required parameters (e.g.,* airflowctl command <val>*). 2. Supporting both styles for the same parameter, i.e. allowing users to provide either a positional value or an explicit flag (*e.g., --param <val>*) via a pre-processing layer. I lean toward the positional-only approach. While the implementation for the second approach is simple, it introduces a non-standard pattern that many CLI libraries (like argparse) and tools generally avoid. By keeping it positional-only, we avoid the need for custom pre-processing logic and keep the testing surface and documentation much simpler. Since we are pre-1.0, we have the opportunity to pick the standard convention now. Either way works. Curious to hear what others think. Regards, Shivam Rastogi On Sun, 26 Apr 2026 at 17:53, Buğra Öztürk <[email protected]> wrote: > Hey all, > > These are the cases where I would lean toward supporting both styles, even > if it introduces some additional maintenance in `cli_config.py`. The PR ( > https://github.com/apache/airflow/pull/65261) adds a thin compatibility > layer that allows users to call commands either by passing values > positionally or by explicitly naming each parameter. This keeps existing > scripts working as they are, it allows user to be well defined in > automated scripts while also giving users a shorter and more flexible > option for quick commands locally. > > The existing Airflow CLI already uses positional arguments for required > parameters, so this approach still feels familiar. At the same time, adding > support for named arguments gives users an option that can be clearer and > more self-documenting. > > ```example output in case you won't pass the positional argument > > ... > > airflow connections add command error: the following arguments are > required: conn_id, see help above. > > ``` > > There is some cost in maintaining this behaviour, but it is relatively > contained since the mapping is generated automatically from the spec rather > than maintained per command. In return, users get the freedom to choose the > style that fits their workflow. Some prefer explicitness for readability, > others prefer brevity for speed. > > > Open to feedback to make this part the final state. It may not make sense > or against some approaches, I am thinking more from a usability > perspective. Please share your thoughts. > > > Kind regards, > > Bugra Ozturk >
