Jump to:
| Project: | Drush |
| Version: | All-versions-5.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | greg.1.anderson |
| Status: | postponed |
Issue Summary
Site aliases have now evolved to the point where they do not always reference sites; they can contain just a document root, or a remote-host / remote user pair, or even contain just a collection of flags that are applied with drush @a command. Aliases can be combined in useful ways with the 'parent' option, but what if you have multiple aliases and want to apply both to one command? drush @a @b command is not a good option, as that gets us back to the same sort of code we needed to process commands with spaces, and also complicates things when the alias is a parameter to a command (e.g. rsync or sql-sync).
This patch allows drush @a+@b command, which will apply the options of both the a and b aliases and then run command. This is good for all sorts of stuff.
Here is just one example.
Suppose you have an alias @live that contains the remote-host and remote-user for your live server, and another alias @drupal that contains the root of the local drupal sites on the current machine. We already know that @drupal/@sites will give the list of all local sites. With this patch, @drupal/@sites+@live will add all of the items in the @live alias to each element of the sites list, which will effectively produce a list of all of the corresponding remote sites (assuming that the drupal roots and uris are set up in alignment). This patch also allows /path/to/root/@sites to work as it should.
In addition to that example, it is now possible to make collections of flags and options and apply them as needed by name from the command line.
| Attachment | Size |
|---|---|
| addative-aliases.patch | 3.3 KB |
Comments
#1
Great stuff. Hopefully adrian can review this. I'll try also.
We've clearly outgrown our name 'sitealias'. I wonder if we should go for 'option set' or just 'set'. To me, it makes sense to apply an option set to a command. These option sets sometimes specify remote-host, and sometimes they don't. I'm a bit timid about a rename at this stage, but maybe its worth it.
#2
I did notice on lowercase false in the patch ... I pinged adrian.
#3
I am worried about this patch adding even more complexity than we need at this point.
We have 'inheritance' in the form of the parent option, which already allows multiple inheritance. I am a bit concerned about that because i have been unable to verify that it recurs correctly... Now this would introduce another form of inheritance, which in actual fact is more alike with a 'union'.
In my current work I am constructing objects for these aliases, and this is definitely the direction we will need to go for drush 4.x, as it is a _lot_ cleaner. What this would be similar to is saying $context = object1 + object2. Which leaves you without an addressable ID for it, which means it can't be saved and loaded from the hard drive. etc.
What is obvious from my current work is that the 'alias' system will likely completely supplant the current context system in drush 4.0, and with that in mind, i think i am favoring we call them 'named contexts' .. if we could qualify "site aliases" vs [command] "aliases", i think named context is a suitable replacement.
#4
Fabric allows this sort of thing (#628262: Study fabric and build similar on top of backend.inc), so I think it's useful. It's true that @a+@b does not have a single name, but I do cache it as... yes, "@a+@b", and as you observed, if you want to give it a name, you can always use inheritance. (Aside: yes, inheritance recurs correctly, and will even handle circular references -- which should never happen, but it is handled correctly if it does.)
Anyway, I'd like this added; it's only a few lines of code. However, I don't think it would impact me tremendously if it didn't go in.
#5
Well .. i will relent to your judgement.
#6
I'm also worried that we are getting too complex. Lets skip this for 3.0 and see how it fits into the OO model for 4.0 ... I'm willing to change my mind on this if anyone really needs this and inheritance won't suffice.
#7
Naw. I think it's a nifty feature, but I don't think leaving it out will hurt me. I'll roll another patch with just the /path/to/root/@sites thing.