airflow-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kamil Breguła <kamil.breg...@polidea.com>
Subject Re: CLI: Use nested commands instead of flags
Date Tue, 11 Jun 2019 18:28:38 GMT
gcloud use a plurral form.

https://cloud.google.com/sdk/gcloud/reference/compute/instances/list

On Tue, Jun 11, 2019 at 8:08 PM Ash Berlin-Taylor <ash@apache.org> wrote:
>
> To bring up the point that William Pursell brought up in the vote thread:
>
> > Not sure if this is the right place to address minor issues, and
> > perhaps I'm late to the discussion.  It would be much more natural to
> > use singular expressions.  eg,
> >
> > airflow dag list
> > airflow pool list
> > airflow pool add
> > etc.
>
> Does anyone have any opinion about this. I'm fairly ambivalent. What do other tools do
here? (i.e. is there any prior art we can copy)
>
> -ash
>
> > On 11 Feb 2019, at 08:48, Szymon Przedwojski <szymon.przedwojski@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.przedwojski@polidea.com
> >
> >> On 8 Feb 2019, at 11:50, Kamil Breguła <kamil.bregula@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.carp@gmail.com <jm.carp@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.bregula@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>
> >
>

Mime
View raw message