Site alias location filters

[greg-1-anderson]

Allow site aliases to be referred to by a 'location' component of the alias name that is based on the name of the folder the alias file is stored in.

See the PR at consolidation/site-alias#1

[greg-1-anderson]

Motivation:

1. The ability for an isp to put all of their aliases in a group so that users can list them via drush sa @isp is very important.
2. If a user is moving a site foo from one isp to another, they are likely to also name the site foo in the target location. If the isp's are creating the site aliases, it would be very inconvenient for the user if both sites could not be named foo, as they will probably create the new site before discovering the conflict.

Beyond these use cases, maintaining the user experience of being able to address a site as either @isp.foo.dev or @foo.dev is important. Naming all of the aliases isp-foo would prevent the use of the short form.

See the above-referenced PR for implementation. Unlike the previous "alias groups" implementation, this version does not add much additional complexity to the site alias package.

[weitzman]

I'm OK with this PR. Feel free to merge when you are ready.

My preference is for aliases to stay simple both in their code and in their mental model. As you mentioned, the code changes here and in consolidation/site-alias#1 are not too onerous.

However, I feel like we were making progress with the message that sites should check their aliases into their codebase in /drush. That gives every team member the same experience when running remote commands from their local. It also lets the alias format vary as long as it matches the drush thats in the same repo. so the user controls everything in the repo and can upgrade with confidence. this story gets slightly muddled with this PR as ISPs are going offer aliases again outside of the repo. now we have a versioning mismatch potential, and we have a 'but how do i run commands on my remote sites' problem.

There is a real tug of war going on between 'drush for site owners' and 'drush for isps'. this PR s for the ISPs IMO. same for the "drush8 as global launcher" PR. not sure how to resolve the tension.

[weitzman]

this sentence is awkwardly placed. i'm not sure what 'this' refers to.

[greg-1-anderson]

Yeah, checking aliases into the site requires a local working copy of the sites codebase to work. The use case of not having a local working copy is more of a convenience for "drush for isps". The "Download Drush Aliases" button is popular.

I'll fix up the text in example.site.yml that follows the text I added.

[greg-1-anderson]

I updated this PR to use site-alias:^1, and also corrected the documentation.

Note that users do not get the @location... feature unless they opt-in to it by adding an alias file location to their configuration text. I have a suggestion related to that. We could reduce the example.site.yml file to just the canonical use-case, and then put more advanced topics in advanced.site.yml or something like that?

If we do that, then is adding a global @foo.dev for your local working copy part of the canonical use-case? Doing that requires adding a location to your drush.yml config file. Maybe enough folks want to do that that it should go in the canonical documentation -- or maybe we want to keep the canonical documentation literally as short as possible, and put everything else in the "advanced" file.

[weitzman]

I think we should try to keep one example file. Lets try over time, in the same file, to fence off the Advanced info.

[greg-1-anderson]

I'll merge here for now and try adding an "ADVANCED" section at the bottom later.