Helper function to generate an alias record for the specified site: drush alias-add @aliasname [#736686]

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];

  unset($alias['name']);
  unset($alias['path-aliases']);

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

Comments

Comment #1

greg.1.anderson CreditAttribution: greg.1.anderson commented 9 March 2010 at 01:02

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?

Comment #2

adrian CreditAttribution: adrian commented 9 March 2010 at 02:44

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).

Comment #3

dman CreditAttribution: dman commented 9 March 2010 at 04:27

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.

Comment #4

greg.1.anderson CreditAttribution: greg.1.anderson commented 9 March 2010 at 22:03

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).

Comment #5

anarcat CreditAttribution: anarcat commented 14 April 2011 at 15:41

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.

Comment #6

anarcat CreditAttribution: anarcat commented 14 April 2011 at 15:42

Component:

PM (dl, en, up ...)

» Base system (internal API)

Better category...

Comment #7

greg.1.anderson CreditAttribution: greg.1.anderson commented 14 April 2011 at 16:46

That sounds cool to me.

Comment #8

moshe weitzman CreditAttribution: moshe weitzman commented 14 April 2011 at 17:20

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.

Comment #9

greg.1.anderson CreditAttribution: greg.1.anderson commented 11 September 2013 at 10:51

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.