Thanks Jarek! I hoped there would be more voice :) If there are no further ideas or feedback, there will still be room for more voices in the consensus. I will follow up with Lazy Consensus on the `required = positional` only approach. Let's go with simplicity and easier maintenance. Great to see no one disagrees with changing how they use airflowctl today with the current parameters.
After the lazy consensus passes, let's revive your MR Shivam. I will close mine and will put a comment on yours with the consensus link. We can continue from there :) Kind regards, Bugra Ozturk On Sat, May 2, 2026 at 2:38 PM Jarek Potiuk <[email protected]> wrote: > 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 > > > > > > > > > >
