I also think it makes sense to group the CLI. It would be nice to in the future for 2.0 release.
On Mon, Feb 11, 2019 at 9:49 AM Szymon Przedwojski < szymon.przedwoj...@polidea.com> wrote: > +1, I like the general idea of refactoring this and the new command > suggestions by Kamil look nice and coherent to me. > > Szymon Przedwojski > Polidea | Software Engineer > > M: +48 500 330 790 > E: szymon.przedwoj...@polidea.com > > > On 8 Feb 2019, at 11:50, Kamil Breguła <kamil.breg...@polidea.com> > wrote: > > > > I think that it is worth to group some commands. > > > > Currently, the user must choose from a large number of commands, which > may > > not be intuitive for the developer. Grouping several command will make > it a > > lot more enjoyable. > > > > airflow resetdb => airflow db reset > > airflow initdb => airflow db init > > > > airflow list_dags => airflow dag list > > airflow trigger_dag dag_id => airflow dag trigger dag_id > > airflow unpause dag_id => airflow dag unpause dag_id > > airflow list_dag_runs dag_id => airflow dag list_runs dag_id > > airflow list_tasks dag_id => airflow dag list_tasks dag_id > > airflow dag_state dag_id => airflow dag state dag_id > > airflow backfill dag_id => airflow dag backfill dag_id > > > > airflow render dag_id task_id execution_date => airflow ti render dag_id > > task_id execution_date > > airflow test dag_id task_id execution_date => airflow ti test dag_id > > task_id execution_date > > airflow task_state => airflow ti state > > airflow run => airflow ti run > > > > And other... > > > > This way of building CLI UI is common in the industry. For example > gcloud ( > > https://cloud.google.com/sdk/gcloud/reference/config/ ) > > > > I think it's worth to prepare AIP to think about building the CLI > > interface. We can introduce the proposed change for only some commands.It > > is worth adding that another interface - REST, have AIP - > > > https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-13%3A+OpenAPI+3+based+API+definition > > > > I personally support the introduction of changes, but we can not make > > changes and think only about one case. First, let's prepare the whole > > interface design, and the next step is to introduce changes. > > > > Thank you very much for thinking about this issues. > > > > > > On Fri, Feb 8, 2019 at 6:27 AM jm.c...@gmail.com <jm.c...@gmail.com> > wrote: > > > >> The CLI treats `airflow connection` as a single command, with `--list`, > >> `--add`, etc. as flags. This means it's possible to pass options that > can't > >> be used together: passing `--list` with `--conn_id` should be invalid. > The > >> current implementation has to handle validation of mutually exclusive > >> options separately for each command. I think the code would be simpler > and > >> easier to use if we used nested commands instead of flags: `airflow > >> connections list` and `airflow connections add` would be separate > >> subcommands that would take different arguments, and we wouldn't have to > >> check for invalid combinations of commands and arguments. > >> > >> This might overlap with other CLI refactoring, like > >> https://issues.apache.org/jira/browse/AIRFLOW-3358. I'm not sure if > that > >> conversation is still active, though. > >> > >> Interested to get feedback about this--maybe there are advantages to > using > >> flags instead of subcommands that I haven't thought of. > >> > > > > > > -- > > > > Kamil Breguła > > Polidea <https://www.polidea.com/> | Software Engineer > > > > M: +48 505 458 451 <+48505458451> > > E: kamil.breg...@polidea.com > > [image: Polidea] <https://www.polidea.com/> > > > > We create human & business stories through technology. > > Check out our projects! <https://www.polidea.com/our-work> > > [image: Github] <https://github.com/Polidea> [image: Facebook] > > <https://www.facebook.com/Polidea.Software> [image: Twitter] > > <https://twitter.com/polidea> [image: Linkedin] > > <https://www.linkedin.com/company/polidea> [image: Instagram] > > <https://instagram.com/polidea> [image: Behance] > > <https://www.behance.net/polidea> > > -- Jarek Potiuk Polidea <https://www.polidea.com/> | Principal Software Engineer M: +48 660 796 129 <+48660796129> E: jarek.pot...@polidea.com
