non-drupal support: allow for downloading modules from other locations to other locations

So it seems I can coerce drush_make into downloading those evil other CMSes we love so much:

core = 6.x
api = 2

projects[drupal][download][type] = "get"
projects[drupal][download][url] = "http://wordpress.org/latest.tar.gz"

As insane as this looks, this actually works:

$ drush make ~/alien.make
Make new site in the current directory? (y/n): y
Project information for drupal retrieved.                                                                   [ok]
drupal downloaded from http://wordpress.org/latest.tar.gz.                                                  [ok]
$ ls
index.php        wp-app.php            wp-config-sample.php  wp-links-opml.php  wp-rdf.php       wp-signup.php
license.txt      wp-atom.php           wp-content            wp-load.php        wp-register.php  wp-trackback.php
readme.html      wp-blog-header.php    wp-cron.php           wp-login.php       wp-rss2.php      xmlrpc.php
wp-activate.php  wp-comments-post.php  wp-feed.php           wp-mail.php        wp-rss.php
wp-admin         wp-commentsrss2.php   wp-includes           wp-pass.php        wp-settings.php

Call me crazy, but even though this is probably not a desired effect, I feel this is actually a nice feature to have, especially for Aegir, which is more and more based on drush make. If we want to support other "platforms" than Drupal, then Drush make could help us big time!

So I feel that while this works, a couple of improvements could be done here. In a few steps:

1. change those notices to read "wordpress" instead of Drupal (ie. support other cores)
2. allow overriding the default upstream repositories for different "cores"
3. allow download and install of extensions for other "cores"

Let's take this one at a time.

Supporting another core type

This is the key idea here. I think that this should be fairly easy to do, but maybe hard to do *right*. Basically, I think the makefile should look something like this instead:

version = 3.x
api = 2
type = wordpress

projects[wordpress][download][type] = "get"
projects[wordpress][download][url] = "http://wordpress.org/latest.tar.gz"

That way the messages would be showed right. Note that this would also add support for Drupal distributions that do not sit on Drupal.org (even though we don't like that).

Changes necessary here:

* parse the type option in the makefile (of course defaulting to "drupal" if not present)
* look for projects[$type] instead of projects[drupal] in the makefile
* change all occurrences of "drupal" in the messages and codebase to "$type"
* support the new "version" parameter (optional, core remains as backward-compatibility deprecated shim) - idea is to remove the confusion between core and type

allowing upstream urls overrides

This is a tad more complicated, and less a priority, because it can be done by manually entering the right URLs in subprojects. *But*, if we parametrize the core type, then we can call different hooks based on that type, and third party extensions to drush can implement their own ways of telling what is "the latest version url". If this is done right, we could have a much simpler makefile:

version = 3.x
api = 2
type = wordpress

.. and the hooks would look on wordpress.org (or wherever) to find what is the latest version.

Changes necessary:

* wrap the current update.drupal.org logic behind hooks
* call those hooks, based on the type
* define another hook, as an example

I'm really worried about the first step here. :)

downloading extensions for other cores

Then the ultimate achievement is to extend those hooks again to allow downloading of third party modules. To again take the example of wordpress, this could look like:

version = 3.x
api = 2
type = wordpress

projects[] = "buddypress"

... which would download buddypress in the right place.

Changes necessary:

* wrap the current logic to find where to put modules ("sites/all or sites/foo?") behind hooks
* wrap the current update.drupal.org logic to find modules behind hooks (maybe the same as step 2)
* call those properly

Conclusion

While this is an ambitious project, I don't expect a lot of people outside the aegir community to have an interest for this, so I am not going to push this very hard, and could settle for just step 1. :) However with this, Drush make could grow to a very versatile deployment tool that would be cross-VCS *and* cross-CMS.