Extend pm-enable to offer downloading the project for missing extensions

What if there was something like this.......

$ drush en views cpn
views was not found.                                              [warning]
cpn was not found.                                                [warning]
Would you like to download the missing projects? (y/n): y
Project views (7.x-3.0) downloaded to sites/all/modules/views.    [ok]
Project cpn (7.x-1.4) downloaded to sites/all/modules/cpn.        [ok]
The following extensions will be enabled: views, cpn
Do you really want to continue? (y/n): y
cpn was enabled successfully.                                     [ok]
views was enabled successfully.                                   [ok]

Yeah, I was going to suggest the same thing. drush en will already try to find dependencies; it should also try to find the projects for the modules requested if they do not exist per #1.

n.b. the "find dependencies" feature was broken by pmtng, but it's probably a small fix to get it back.

In addition to #1 by Rob Loach:

drush dl views
Project views (7.x-3.0) downloaded to sites/all/modules/views.    [ok]
Do you want to enable views? y/n:

and

drush dlen views
Project views (7.x-3.0) downloaded to sites/all/modules/views.    [ok]
views was enabled successfully.                                   [ok]

Put together "An other" to make "Another"

I would love this!

Yes, this would be awesome.

Here is a really simple implementation of this. It just tries to download the projects it can not find. I already have something like this in a bash script, but found this issue while trying to see if others had any implementations of it. So why not try to get it commited to drush core.

Command output following. First let's try something simple:

$ drush en ctools
The following projects could not be found:
ctools
Would you like to download them? (y/n): y
Project ctools (7.x-1.2) downloaded to                                       [success]
/var/www/dtest/sites/all/modules/ctools.
Project ctools contains 9 modules: stylizer, views_content, bulk_export, ctools_custom_content, ctools_plugin_example, ctools_ajax_sample, page_manager, ctools_access_ruleset, ctools.
The following extensions will be enabled: ctools
Do you really want to continue? (y/n): y
ctools was enabled successfully.                                             [ok]

An example with dependencies:

$ drush en views
The following projects could not be found:
views
Would you like to download them? (y/n): y
Project views (7.x-3.5) downloaded to /var/www/dtest/sites/all/modules/views.[success]
Project views contains 2 modules: views, views_ui.
The following projects have unmet dependencies:
views requires ctools
Would you like to download them? (y/n): y
Project ctools (7.x-1.2) downloaded to                                       [success]
/var/www/dtest/sites/all/modules/ctools.
Project ctools contains 9 modules: stylizer, views_content, bulk_export, ctools_custom_content, ctools_plugin_example, ctools_ajax_sample, page_manager, ctools_access_ruleset, ctools.
The following extensions will be enabled: views, ctools
Do you really want to continue? (y/n): y
ctools was enabled successfully.                                             [ok]
views was enabled successfully.                                              [ok]

And an example where the project does not exists:

$ drush en unknown_stuff
No release history was found for the requested project (unknown_stuff).      [warning]
There were no extensions that could be enabled.                              [ok]

Here is an example of a mixture between a project with dependencies and a project that does not exists:

$ drush en unknown_stuff views
No release history was found for the requested project (unknown_stuff).       [warning]
The following projects could not be found:
views
Would you like to download them? (y/n): y
Project views (7.x-3.5) downloaded to /var/www/dtest/sites/all/modules/views.[success]
Project views contains 2 modules: views, views_ui.
The following projects have unmet dependencies:
views requires ctools
Would you like to download them? (y/n): y
Project ctools (7.x-1.2) downloaded to                                       [success]
/var/www/dtest/sites/all/modules/ctools.
Project ctools contains 9 modules: stylizer, views_content, bulk_export, ctools_custom_content, ctools_plugin_example, ctools_ajax_sample, page_manager, ctools_access_ruleset, ctools.
No release history was found for the requested project (unknown_stuff).       [warning]
The following extensions will be enabled: views, ctools
Do you really want to continue? (y/n): y
ctools was enabled successfully.                                             [ok]
views was enabled successfully.                                              [ok]

As you can see, the warning of not found pops up twice. Not sure how to avoid that when dealing with dependencies. Also, I find it quite OK that i can see it almost at the end also that something went wrong.

Lastly, here is an example of enabling an already downloaded example (with a dependency just to be cool):

$ drush en views
The following projects have unmet dependencies:
views requires ctools
Would you like to download them? (y/n): y
Project ctools (7.x-1.2) downloaded to                                       [success]
/var/www/dtest/sites/all/modules/ctools.
Project ctools contains 9 modules: stylizer, views_content, bulk_export, ctools_custom_content, ctools_plugin_example, ctools_ajax_sample, page_manager, ctools_access_ruleset, ctools.
The following extensions will be enabled: views, ctools
Do you really want to continue? (y/n): y
ctools was enabled successfully.                                             [ok]
views was enabled successfully.                                              [ok]

Please review. Would be an awesome feature to have!

I like #7 better than item 2 in the O.P. Haven't tried the patch, but the code looks pretty good. I'm indifferent about whether unknown stuff should fail fast, or just keep going per the current implementation. If id doesn't fail fast, warning twice is okay.

Could use a test.

Works for me. Thank you!

Thanks for reviewing.

New patch, now including a simple test as well.

...or maybe like this, so we do more like the code comment say we do.

Sorry this got lost. Hopefully jonhattan can have a look, and others can review. I'm not that hot on compound commands anymore but this one sure is useful.

Sounds good. Since I noticed you changed branch for this, I just verified the patch still applies to 8.x-6.x-dev.

Just out of curiosity: Is there a reason this can not get in 5.x?

The policy is that all new patches go in 8.x-6.x first, and patches that are backported to 7.x-5.x cannot break or change existing functionality. Therefore, this patch could go into 7.x-5.x, as it extends but does not change existing behavior.

Sure, looks fine. The drush_set_context('DRUSH_AFFIRMATIVE', FALSE); still bugs me; it would be better to set a backend option that cleared the --yes flag in backend invoke. Feel free to ignore that, or open a new issue for it and assign it to me.

Looks good to me. I set the title to what the current patch actually does (as far as I can tell)