The devel hook drush_devel_post_enable (which should now be named drush_devel_post_pm_enable now) will never be called (even if correctly renamed), because drush now will only allow enabled modules to participate in command hooks. All modules, enabled or no, were formerly included, so this used to work.
There needs to be a good way for modules to automatically download their dependencies. We could punt on this and recommend using the Drupal dependency check for this, but putting it in a drush hook as devel did has the advantage that you can show progress, prompt the user, etc.
We could attempt to make the pm-enable command explicitly add modules being enabled to the drush commandfile list (if they have drush commandfiles). This would be pretty easy to do in drush_init_pm_enable. Alternately, we could add special code to pm-download to give modules a chance.
I think I favor the former. Thoughts?
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | drush-pm-enable.patch | 2.61 KB | greg.1.anderson |
Comments
Comment #1
greg.1.anderson commentedHere is a patch. It adds commandfiles from modules that are being enabled during the pm-enable stage. This allows them to participate in the post_pm_enable hook, so devel works again with this patch (provided its hook is renamed to drush_devel_post_pm_enable). Pretty simple change, and useful for a number of things.
Comment #2
moshe weitzman commentedYeah, looks real good to me. Committed, along with devel rename in d6 and d6.
Comment #3
greg.1.anderson commentedThanks!
Comment #4
moshe weitzman commentedJust noticed that when you abort a pm-enable during confirmation, our 'post' hooks still fire and download your extra code. Should the abort of a pm-enable be considered an error which stops the 'post' commands and triggers rollback?
Comment #5
greg.1.anderson commentedYes! #1008118: Standardize on `return drush_user_abort();` as correct way to stop execution when user cancels