The first version of this patch will load aliases from the new location or drushrc.php. We can decide whether to remove the current mechanism, or keep it in place. Because of the way aliases work, we would have to go out of our way to prevent them from being defined in drushrc.php, so perhaps it should remain a sanctioned place.
There will be a default search path for the alias file location, which will default to the drush install directory, /etc and $HOME/.drush, and additional folders can be specified in any drushrc.php file loaded during the DRUSH_BOOTSTRAP_DRUSH phase, or via command-line options.
Inside the search path, drush will look for files named 'aliases.drushrc.php' and '$aliasname.alias.drush.php'.
Alias definitions will be searched for when they are referenced. Every time a local site is referenced by an alias, its site folder will be added to the alias file search path, so site-specific aliases (e.g. '@peer') may be defined.
Comment | File | Size | Author |
---|---|---|---|
#14 | alias-separate-includes-3.patch | 29.81 KB | greg.1.anderson |
#5 | alias-separate-includes-2.patch | 30.11 KB | greg.1.anderson |
#2 | alias-separate-includes.patch | 27.25 KB | greg.1.anderson |
Comments
Comment #1
moshe weitzman CreditAttribution: moshe weitzman commentedthanks for kicking this off.
i don't want two different ways of doing things. i'd rather not allow aliases in drushrc and if we must, lets not advertise as a feature ... i have no desire to provide backwards compat for 3.0 since it isn't released yet.
Comment #2
greg.1.anderson CreditAttribution: greg.1.anderson commentedThis patch includes the code from #733244: Aliases should be named '@alias' instead of 'alias' and #727058: Site aliases should not be cached in the options context.
The main logic looks like this:
_drush_sitealias_load_alias is called whenever a command looks up an alias ("@aliasname") via drush_sitealias_get_record. Note that under this implementation, we do not cache alias records in any context unless the alias is fetched; unused aliases are ignored.
drush_sitealias_load_all is called only by the
drush site-alias
command, and only when there are no parameters. It fetches every alias it can find, and prints its name (or the whole thing if --full is used).Finally, this patch prevents aliases from being defined in drushrc.php files via a call to
unset($options['site-aliases']);
placed immediately after the drushrc.php file is loaded. It is still possible to nest alias records (define one alias inside another).Yes, the documentation needs to be updated now, but this is a good starting point for further discussion.
Comment #3
moshe weitzman CreditAttribution: moshe weitzman commentedThat excerpted code and explanation look good to me. As you said, lets get some doxygen in here before commit ... adrian is planning to review this over the weekend.
Comment #4
greg.1.anderson CreditAttribution: greg.1.anderson commentedAfter sleeping on it, it was my consideration that this snippet:
Should instead be:
This would allow myalias.alias.drush.php to define $options the same way that they are defined in drushrc.php, or it can define an alias the same way that it would be defined in aliases.drushrc.php. This would also require some small changes to the alias processing on the lines below, to insure that $options became part of the alias. This feature would also benefit aliases.drushrc.php in that you could define some $options at the top of the file, and they will be applied to all aliases in the file. This also implies that perhaps the code should look for *.aliases.drushrc.php in addition to aliases.drushrc.php, so that people could make groups of aliases, if desired.
I'll try to update tonight, but it is not likely I will have time to do it. I'll add doxygen and example.aliases.drushrc.php, and update example.drushrc.php after Adrian's review.
Comment #5
greg.1.anderson CreditAttribution: greg.1.anderson commentedHere's a patch that includes the ideas from #4. This allows you to define an alias file that looks like this:
servername.aliases.drushrc.php:
The $options are copied into every alias.
Similarly, put this in your 'sites' folder to define an alias @peer, valid only for that site:
peer.alias.drushrc.php:
You can also use
$aliases['peer'] = array(...)
if you prefer.Comment #6
adrian CreditAttribution: adrian commentedI have tested this patch, and it seems to be working fine. I also like how it's been implemented. AFAICT it's not possible to set aliases in a drushrc.php anymore.
I'm still a bit unclear about a couple of things.
If both ~/.drush/aliases.drushrc.php and ~/.drush/aliasname.alias.drushrc.php are defined, which one takes precedence?
I also feel that we should be using a subdirectory in ~/.drush (or /etc/drush, or wherever), to keep the alias definitions together.
This has become a bit of a hydra of a patch, so i think we should close the other related items and hash it all out here.
(setting it to needs work, because that's the closest to what the actual status is ... i feel this patch is very nearly there)
Comment #7
adrian CreditAttribution: adrian commentedSomething I will likely be using, and might have to implement myself is inheritance.
IE : each alias can have a parent alias.
Similar to your first example regarding the options but the 'servername.alias.php' defines only remote_host / remote_user.
Then the platformname.alias.php defines only the drupal root, and then the sitename.alias.php defines just the URI component.
This means I can keep them up to date separately.
Your second format (ie: $options), actually allows me to simply include the necessary parent from my generated site alias record.
Comment #8
greg.1.anderson CreditAttribution: greg.1.anderson commentedCan I suggest that if there are no immediately obvious bugs in this issue (and the two it depends on) that we go ahead and commit it, mark it fixed, and continue with additional enhancements in separate issues? I'll accept necessary changes here, but some of the enhancements, I think, would be easier to discuss in separate issues where the diffs can be smaller.
You are right -- based on a comment by Moshe, I explicitly prohibit alias definitions in drushrc.php from working. They could be allowed again by removing one 'unset' from the code and adding back in the $aliases to $options['site-aliases'] copy that was there before.
Regarding precedence, right now it is not defined. The loop does not terminate, so the last encountered alias will win. If a 'terminate when found' condition is put in, then the first encountered alias could win. Precedence could be adjusted by tuning the order of the search path and search files. I tend to think that most people won't mix the different kinds of alias files, so precedence will not be a big issue.
The current places that alias files are searched for are as follows:
/etc/drush
DRUSH
DRUSH/aliases
$HOME/.drush
This could easily be changed to:
/etc/drush/aliases
DRUSH/aliases
$HOME/.drush/aliases
... or the two lists could be merged. It's possible to define what the search path should be by setting
$options['alias-path'] = '/etc/drush/aliases'
in drushrc.php, so adjusting the default search path is not critical, IMO. This does need to be documented, but I'm holding off on documentation until we're agreed on core features & this patch is committed.You are right that inheritance would not be too hard to implement, and can to a certain extent be achieved today via $options syntax and 'include'. I'd suggest future enhancements in this area be discussed in a separate issue.
I don't think any of the above changes need to be made; if you'd like any of the suggestions above implemented, let me know explicitly which way you think it should go and I'll roll another patch. Otherwise, let's go ahead and get this committed.
Thanks for your review.
Comment #9
adrian CreditAttribution: adrian commentedIn a completely non-pedantic way, I think we should go through the documentation, the following functions are missing phpdoc :
The missing documentation and the rather esoteric operation of this stuff means that there is a rather high WTF quotient if you are not used to the code. Not a dealbreaker, but still isn't making this any easier.
Comment #10
adrian CreditAttribution: adrian commentedgreg .. i am fine with this being committed, and work being done on it further.
fyi ..the sitelist functonality is also broken.
Comment #11
greg.1.anderson CreditAttribution: greg.1.anderson commentedI'll look into the sitelist feature and repair as required, and then I will document the code and commit.
Repairing _drush_sitealias_get_record will have to wait for a later time -- hopefully not too much later. I want to get rid of the evil that is $db_settings_needed too.
Comment #12
adrian CreditAttribution: adrian commentedi was trying with :
drush @sitealias1,@sitealias2 status
Comment #13
greg.1.anderson CreditAttribution: greg.1.anderson commentedYeah, that should work all right. I'll look into it and see what broke it.
Comment #14
greg.1.anderson CreditAttribution: greg.1.anderson commentedFor reference, here is the fix for the bug in #12.
I'll commit this whole thing once I've put in some doxygen.
Comment #15
greg.1.anderson CreditAttribution: greg.1.anderson commentedCommitted. Docs still need need some help (especially example.aliases.drushrc.php), but I've made a decent start.