I'm looking into writing a command to save records to the new alias files, but the logic in sitealias.drush.inc is rather obtuse.

At the very least, the actual discovery of the site record should be abstracted out into a function that returns said value, and all the print_record should be is a call to generate the record, and then print the result. This would mean that the internals were re-usable.

what I ended up with was :

  $filename = drush_get_option('alias-path', '') . "/$url.alias.drushrc.php";
  $alias = drush_sitealias_resolve_sitespecs(array($url), true);
  $alias = $alias[$url];


  if ($fp = fopen($filename, "w+")) {
    fwrite($fp, "<?php\n");
    fwrite($fp, "\n\$aliases['$url'] = ". var_export($alias, TRUE) . ';');

This may be related to :
#727050: Drush should be able to fetch site aliases remotely


greg.1.anderson’s picture

The key here is where to write the alias file. If 'alias-path' is set, then the code above is copasetic, but what if it is not? Where does the alias file get written then?

I think maybe you meant drush_get_option('alias-path', '.'), which would write it to the current working directory... well, after drush changes the CWD... maybe we should look up the saved working directory?

adrian’s picture

it was just some test code i was playing with.

In aegir i generate drushrc.php files inside the $drupal_root and the site root. I just tied that code into the drushrc.php creation inside the site root. To test it, i added $options['alias-path'] in my ~/.drushrc.php, but the actual implementation will be cleaner.

I tried setting the alias-path in a hook_drush_init in one of my commandfiles, but it gets loaded too late. As I said, i'm still just testing the limits of the API.

I have some other things I need to get in order first, but my goal is to store a $AEGIR_CONF/drush.d directory, filled with the aliases.
This way I don't overwrite any of the user specified aliases (hopefully).

dman’s picture

I've been doing similar things myself, actually trying to write a bootstrap wizard that sets up peering between sites, by asking for connection details etc for the target. Messy messy code at my end currently.
I'm saving my site details in drushrc in the site folder, but haven't thought too hard about it.
so subscribe.

greg.1.anderson’s picture

Title: Helper function to generate an alias record for the specified site » Helper function to generate an alias record for the specified site: drush alias-add @aliasname

Hijacking this issue to indicate an actual feature request for drush: the alias-add command.

The thing I still need to wrap my head around is, if drush alias-add @aliasname copies the values from "@self" (taken from --root and --uri or cwd or whatever) into the new alias "aliasname", and drush /path/to/local/site#uri alias-add @aliasname does something very similar (in this case @self is initialized to -r=/path/to/local/site and -l=uri), then what about remote aliases? By default, if you put a remote site specification on the left side of the command, then drush is going to run the command on the remote machine, which means that you'd be adding an alias on the remote site.

I haven't completely decided what the right parameters are, but I think that remote sites are going to need to be specified on the right-hand side of the command, unless we change the way that command dispatching works. Maybe remote sites on the left side of the command do not execute remotely for some commands (e.g. sql-sync, rsync and alias-add, to name three).

anarcat’s picture

Component: Code » PM (dl, en, up ...)

Note that this exists in provision right now. It's called provision-save, and allows to save specific objects into aliases. It's tightly coupled with Aegir's provisionConfig class which takes care of the loading and storing of data and writing config files for Aegir.

I also suspect it may be coupled with the more complex provisionContext class, but it doesn't look like it at first glance.

Aegir is strongly interested in factoring this upwards into Drush 5 for Aegir 2.

anarcat’s picture

Component: PM (dl, en, up ...) » Base system (internal API)

Better category...

greg.1.anderson’s picture

That sounds cool to me.

moshe weitzman’s picture

Yeah, I'm interested in moving code from provision to drush ... We have a drush_save_config() function which might be similar to the alias-add.

greg.1.anderson’s picture

Version: » 8.x-6.x-dev
Status: Active » Closed (won't fix)
Issue tags: +needs migration

This issue was marked closed (won't fix) because Drush has moved to Github.

If this feature is still desired, you may copy it to our Github project. For best results, create a Pull Request that has been updated for the master branch. Post a link here to the PR, and please also change the status of this issue to closed (duplicate).

Please ask support questions on Drupal Answers.