I am also more for the "required = positional". It's a bit confusing if you can do both .
On Tue, Apr 28, 2026 at 10:03 PM Buğra Öztürk <[email protected]> wrote: > 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 > > > > > >
