Interactively gather site argument about terminus

[mikevanwinkle]

Yep, I agree but actually many of these above are already available namely:

site (need to add this one)
env (already there)
org (already there)
product ( already there ... at least in creating a site )
bucket ( hmmm this one I have "backup" because there's not a clear concept of what a "bucket" it is in the dashboard so I thought it was confusing ... but I'm open to discussion)
element ( need to add it )
branch ( need to add it )

This should be a quick thing I can get out this week.

Right now most of this interaction is in the command controller itself but I've started moving them to php/Terminus/Helpers/Input

[mikevanwinkle]

I'm not a fan of how the old Terminus has just one massive function with a switch statement, makes it hard to read and find what your looking for. That's why I'm going with the Helper\Input approach

[mikevanwinkle]

On this topic I would like to brainstorm about how we might auto populate the "site" based on being in the local site root. I was thinking that we could maybe create a feature to where if a terminus.yml file exists in the working directory then values for options could be grabbed from there ... just an idea and maybe it belongs on another issue.

[joshkoenig]

Oh word? Maybe we just need to get the site one done, since that's what I first encounter. The others are more gravy we can look to improve over time.

[dustinleblanc]

Another idea is to store The config in the git config: git config psite.uuid foo-bar-baz...

[mikevanwinkle]

Hmmm ... that's an interesting idea as well

[dustinleblanc]

based on this article btw http://www.triquanta.nl/blog/automatically-switch-drush-versions-project I have been using this system to seperate my D7 / D8 stuff

[joshkoenig]

While it's a neat idea, I believe terminus.yml > git config

Reasons:

1. Terminus should be self-contained. We should assume as little as possible about the user environment. Most users will have a working install of git, but maybe not all.
2. Git config has multiple scopes (global, user, repository) which could get screwy.
3. Plenty of other things may affect git config, which could lead to unpredictable behavior.
4. If Terminus owns its own config, it's much easier to debug. (e.g. "Gist me your terminus.yml file" is an easy request.)

[dustinleblanc]

good arguments, and probably what I would choose.

I simply have an aversion to adding files to my repo :) I get tired of typing ls and seeing 15 files in my site root that are all tiny config files for each and every dev tool the team is using (such as a gemfile, guardfile, gruntfile, package.json, travis.yml...and the list grows as everybody uses their favorite tool) so simply not having another file to worry about versioning or not is appealing.

That said, as a 'fits the most cases' use, a terminus.yml is probably better even if it is less convenient for some like me.

for the sake of fun and giggles, couldn't you also generate a file in a user's .terminus directory with a key of the docroot location and a value of the pantheon uuid? Not that it's better, but it's another way to not add yet another file to the repository that some users may use.

~/code/php/drupal/meridian-180 : uuidstringzorzzz
~/code/php/wordpress/foo : otheruuidomgsolongcantreadddd

it also strikes me as more the convention pantheon has used in the past. It took me a while to get used to drush alias files living in ~/.drush but now I'm hip with that paradigm.
</ armchairpotstirring>

[joshkoenig]

I'd be in favor of having a ~/.terminus dir. I think we're already doing that for data caching, so no reason we couldn't have that be a default place for stuff like this to live.

[bensheldon]

I think this issue has evolved to become a dupe of #221.