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 <a...@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.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> > > >
