Override alias context options by defining an @self alias

I was actually planning on unioning info from an alias in sites/SITENAME/self.alias.drushrc.php (or something equivalent) into @self whenever a site is bootstrapped -- but I have not done so yet.

Rather than modifying the @self alias as suggested in #1, a better thing to do is to just put a drushrc.php config file in the site context. This already works for adding new options to your context.

The enclosed patch reduces the priority of the 'alias' context so that drush and site context options can also override settings in @self.

I recently had to experiment a bit to settle on this solution. Would be good to more explicitly document how to set options for the 'default' site. i needed it for sql-sync.

On that note, I was wondering how one can set 'command_specific' options in a site alias. Would be good to add an example if thats supported.

Patch looks good

Committed

Assigning back to Greg in case we can do something about the documentation requests in #5. If not, please move back to Fixed.

I'll document this.

Thanks.

Can one specify $override in a site alias. This overrides drupal's variable_get(). See bottom of example.drushrc.php. If yes, lets document it. If not, consider this a feature request.

Here's the documentation for command specific in an alias.

The other two items are feature requests. It turns out that #4 is true in the general case, but not in the case of rsync or sql-sync, as the target sites are not bootstrapped. I'll make sure that their drushrc.php contexts are loaded anyway. $override in alias files is not implemented, but should not be hard.

Thanks. Looks good. Found two typos

'druch'
'precidence' (twice)

We can close this one after the docs go in. I'll open a new issue for overrides and other wishes for drush5.

Docs have been committed.

I'm re-opening this as a marker. I'm going to try some things; there may be some advantages to modifying @self over placing options in a site's drushrc.php. Maybe I'll re-close without making any changes.

#4 is not satisfying for a couple of reasons. First, it does not work with sql-sync, so the original request is not met by this workaround. Second, it is important that the alias context have a higher priority than the site context so that you can define special aliases for sites that override the options defined at the site level.

This patch rolls back the context priority change (well, not quite rolls back: command-specific is still a higher-priority context than alias so that command-specific options in aliases override options of the same name in the alias). It also adds a bit of infrastructure so that options set in the drushrc.php file of a site affect sql-sync when an alias for that site is used as a target.

Two changes accomplish this:

1. backend invoke passes the 'self' alias for the completed command back with the other results in the results array. The 'site' context is first merged into the self alias record.

2. drush_sitealias_add_db_settings (called by sql-sync to look up the database settings) will merge the values from the 'self' alias record in the backend invoke results array into the alias record used to fetch the db results.

In this way, sites can define shared settings in a drushrc.php file in the Drupal site folder (same folder as settings.php), and options set there will be applied to sql-sync operations on that site, even remotely.

This needs better docs, which I will provide once the code is RTBC. It's working very well for me, and increases the power of drush quite a bit.

Code looks good, and I agree that it will be handy. I don't know who will setup a patched remote drush to test this so lets call this RTBC now.

I presume this will only work for the case when db-url is *not* defined in the remote alias. Otherwise, sql-sync would connect to mysql directly and we never get the site context back.

You are correct; if the database info is already available in the alias, then drush will not pick up the site's drushrc.php configuration. Therefore, this is not an alternative to a policy file, it's just a convenience.

Committed.