airflow-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bas Harenslak <basharens...@godatadriven.com>
Subject Re: CLI: Use nested commands instead of flags
Date Tue, 11 Jun 2019 19:52:05 GMT
My 2c: I googled a bit and checked a few other CLIs. The internet is full of people discussing
this topic and there is no straight answer, so pick one and stick with it.

Most CLIs seem to use both plural and singular, depending on whether you’re making a request
to single resource or multiple resources:

Kubernetes: both (e.g. kubectl get pod for single pod, kubectl get pods for all)
Gcloud: plural (e.g. gcloud compute instances move … for moving a single instance)
AWS: both
Docker: both

I think it kinda makes sense to use both forms, since in spoken word we also talk about a
“dag” (singular) when referring to one single DAG, and talk about “dags” (plural)
when referring to multiple DAGs.

Cheers,
Bas

On 11 Jun 2019, at 20:28, Kamil Breguła <kamil.bregula@polidea.com<mailto:kamil.bregula@polidea.com>>
wrote:

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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message