It appears that the 'parent' => '@aliasname' option does not work when @aliasname is defined in a separate alias file. Aliases from this file do work when called directly.

Is this the case for others, and if so is it intentional/necessary or a bug?

(Background: My goal is similar to what i was after in #1167342: Alias patterns, with a different approach: having a project's main Drush settings centrally handled with the project, while what is person-specific - for instance, remote-user - can be overridden locally.)

Comments

greg.1.anderson’s picture

We do need better ways to override group aliases locally; maybe even a drush_alias_alter hook.

'parent' => '@servername' does work fine, though; I have a file called servers.aliases.drushrc.php, and I put all of my remote-host / remote-user definitions there, and refer to the server by name via a 'parent' directive in each individual remote alias.

If you could be more specific about what is not working, perhaps I could help you track it down. The stuff you were doing in the link you reference above looked like it was correct.

mlncn’s picture

That link is what i'm doing--

I am including sdl.aliases.drushrc.php using the alias-path option in my site's drushrc.php, and i have a shared.aliases.drushrc.php file in ~/.drush which might as well not be there as far as the 'parent' mentions in sdl.aliases.drushrc.php.

mlncn’s picture

But it seems i need to abandon drushrc.php for including my aliases because it stops working when the site itself doesn't have a database. drush @sdl.local sql-drop; drush sql-sync @sdl.stage @sdl.local doesn't work too well in that case...

greg.1.anderson’s picture

I think that your gotcha is that if you use the alias-path directive, it removes all of the default alias paths such as ~/.drush. See #957182: Setting $options['alias-path'] in one drushrc.php file should not overwrite default values, or values set in other config files.

It is a bother that site options are ignored unless the site bootstraps correctly. I want to rework the drush bootstrap process a bit more to fix up this sort of issue.

mlncn’s picture

Also:

drush --alias-path='/home/ben/code/sdl:/home/ben/.drush' @sdl.stage status

does not work at all, but:

drush --alias-path='/home/ben/code/sdl' @sdl.stage status

does.

mlncn’s picture

Crosspost, i started thinking along the same lines, hence adding alias paths. And i swore i read about the colon syntax but maybe that was for different paths in Drush, not aliases? Oy.

Yeah it sounds like with the two fixes you are talking about -- allowing drushrc.php to work even when the associated site does not boot strap, and allowing multiple alias locations to be specified -- i would be a most happy camper.

mlncn’s picture

If i put the aliases file in sites it will work without Drush being bootstrapped? About to find out.

mlncn’s picture

No, aliases do not work in the /sites directory of an un-boot-strapable site. Is there an issue for that? (The goal as mentioned is to centrally manage some aliases in a sane way.)

greg.1.anderson’s picture

I enhanced #957182: Setting $options['alias-path'] in one drushrc.php file should not overwrite default values, or values set in other config files to make it easier to merge together aliases without having to resort to '@parent' (which is good for merging in server info, etc., but is awkward as a mechanism to enable overrides).

There is no issue for reading aliases and options from un-bootstrapable sites yet, but I think it would be a good enhancement.

greg.1.anderson’s picture

greg.1.anderson’s picture

Status: Active » Closed (fixed)

Closing - presumed fixed by other issues.