Open mikemilano opened 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
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?
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));
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
That's 32 more characters to type to open a tunnel
2) Site and environment are always arguments, everything else is an option
3) Site, environment, and vars that will be defined in most cases are arguments, the rest are options
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.