Thanks Shivam for joining the discussion! I agree on that side of it, as it will be a bit of a burden and not a standard approach in the CLI stack.
It really depends on what current users feel about it. Indeed, let's hear what others think. I am happy with what most people think or going with the easy positional only approach too. On Mon, Apr 27, 2026 at 4:28 AM Shivam Rastogi <[email protected]> wrote: > 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 > > >
