pantheon-deprecated / terminus-deprecated

Deprecated CLI for Pantheon. Do not install. Current project:
https://github.com/pantheon-systems/cli
82 stars 24 forks source link

Drush command argument & option standards #19

Open mikemilano opened 10 years ago

mikemilano commented 10 years ago

Moved into it's own discussion from #17

The problem: What should be an argument, vs what should be an option?

It would be good to establish a standard for adding Terminus specific Drush commands. Currently, everything is an argument.

Off the top of my head, here are some options for standardizing command arguments & options:

1) Everything is an option

drush psite-tunnel --site=mysite --environment=dev --service=redis --port=4001

That's 32 more characters to type to open a tunnel

2) Site and environment are always arguments, everything else is an option

drush psite-tunnel mysite dev --service=redis --port=4001

3) Site, environment, and vars that will be defined in most cases are arguments, the rest are options

drush psite-tunnel mysite dev redis --port=4001

Yeah, I know, how do you define "in most cases" :) In comparison to 2, you only need to know/type what comes next, and not remember or type the option name every time.

From my perspective, I like 3, but I understand it leaves room for interpretation, so 2 would be my second preference.

patcon commented 10 years ago

My vote for 3, with no default for mysql service (ie. requires 3 args). My thought is that if an argument is optional (ie. has a default), it should probably be an option. The arg

On a related note, are there plans to make the site and env be easily implemented as site aliases? Like is @mysite.dev the format that pantheon aliases use? If the roadmap includes adding support for something like that, then site and env should probably be options too, right?

Usage:
drush @site.env psite-tunnel service_name [ --port=num | --site=str | -- env=str ]

drush @mysite.dev psite-tunnel redis --port=4001
mikemilano commented 10 years ago

In the case of Tunnel, it could be done, but it would have to be considered on a per command basis. It could get confusing if the aliases aren't kept separate from the terminus api arguments.

For example, currently, I have a local alias setup, and I use the alias as the environment I want run the terminus command against. (load my local environment with the latest backup from "dev")

drush @mysite.local psite-load-backup mysite dev

This next one doesn't work yet (not sure it will be supported), but it's an example of a case for executing the Terminus api from a specific Pantheon environment. (load Pantheon multi-dev environment "mike" with the latest backup from "dev")

drush @pantheon.mysite.mike psite-load-backup mysite dev

Any thoughts on how these examples would work with alias targets vs site/env in arguments?

bwood commented 10 years ago

I was about to ask that the one argument (name) to psite-create be converted to an option. My (possibly unenlighted) reasoning for this is that in my training_pantheon script training-1-spinup I resorted to "echo "My site name" | drush psite-create"

$cmd = "$echo $site_name-$I | $drush pantheon-site-create $site_name-$I --product=$product_uuid --organization=$organization_uuid";
/* ...snip...*/
  exec(sprintf("%s > %s 2>&1 & echo $! >> %s", $cmd, $output_file . "-$site_name-$I-out.txt", $pid_file));