5

How can I automatically enable new dependency added on a custom feature (or standard modules) with drush?

After getting the new code, my deployment script basically run:

drush cc all
drush fra

But I need to visit the admin/structure/features page if I added new dependencies otherwise those modules are not enabled. How can I avoid it? Is there a drush command? I can't use drush en thenewmodule because I want to keep my deployment script generic.

  • do drush updb or drush rr work? – David Meister Jun 26 '13 at 13:57
  • No, I'm also running drush updb a bit later in the script. What is drush rr? – gagarine Jun 26 '13 at 14:00
  • I don't think this will help. Modules are not even enable in the system table. I don't have a problem on cache clear but after when I have for example field definition than need a module than is not enable yet. – gagarine Jun 26 '13 at 14:07
  • you could look at drupal.org/project/context_module for an alternative approach – David Meister Nov 3 '13 at 3:58
6

There is a feature request issue in a Drush queue, just stumbled on it. In donquixote's Drux project are commands you need:

drux-enable-dependencies (dep-en) - Download and enable dependencies of existing modules. drux-find-obsolete (obs) - Find modules that are not direct or indirect dependencies of the modules given as arguments drux-generate (obs-gen) - Generate a list of dependencies[] = .. to copy+paste into a module info file. drux-list-dependencies (dep) - List dependencies that would be enabled with drush dep-en. (The help text seems to be wrong).

So for the task at hand, drush dep-en should do the job.

You can download it here.

UPDATE: Now available on github: https://github.com/donquixote/drupal-drux

Alternatives, part I

As pointed out by Jesse Pinho in another answer, you can also run drush fr DEPENDENT_MODULE.

Or you can run drush en DEPENDENT_MODULE.

The difference is that for these commands you need to know the "DEPENDENT_MODULE" which has the added dependencies.

With drush dep-en you can just run the command without any arguments, and it will check all enabled modules for dependencies.

Alternatives, part II

Instead of such drush commands in combination with dependencies, you could also use hook_update_N() to enable additional modules. This seems a common technique for Drupal 7 projects.

See the answer by reubidium.

  • I saw this before, but I think this is the right answer. The issue has to be fixed. – gagarine Jul 4 '13 at 9:06
  • @gagarine well, it seems to me these sandbox commands really works. At least in simplest cases. – Mołot Jul 4 '13 at 9:10
  • @donquixote thanks for your input, and for good work you did. – Mołot Jul 4 '14 at 7:15
  • 1
    "drush dep" only lists the dependencies, whereas "drush dep-en" enables them. I think there is a bug in the help text :) – donquixote Nov 5 '18 at 14:15
  • 1
    @donquixote my answer is from 2013. Now it's 2018 and I'm mostly inactive here. If you are the same donquixote I linked to, feel free to edit my answer for accuracy and updates, I won't object. – Mołot Nov 5 '18 at 14:18
5
+100

I don't think there is a way to get this task completely automated.

But you could use the Master Module to write your dependencies into code. Master provides a framework for module-dependency configuration in automated deployment settings.

  • This is certainly the way to go for now but I don't want my deployment script need any special module. So I give you the bounty but Molot answer my question better... – gagarine Jul 4 '13 at 9:08
4

Note that you can also revert just the dependencies feature of the module whose dependencies you've changed, then run drush fra:

drush fr -y [feature-module-name].dependencies && drush fra
  • Seems to work! But why do you need drush fra afterwards? – donquixote Nov 5 '18 at 14:17
0

You could create a custom module and list all the modules you want to enable on deploy as dependencies of that module in its .info file. Then just enable that module on deploy to enable all the other modules. Drupal will handle their dependencies. If your module always has the same name, you could drush en custom-dependencies -y or whatever you want to call it, and make the contents of that module's .info file specific per-project.

If you're trying to enable new modules on deployment to an already-built site, you can put module_enable() inside an update hook in an already-enabled module. This will go away in Drupal 8, but for current Drupal sites it works fine. So if you have updated an existing module, X such that it introduces a new dependency on module Y, an update hook in module X's .install file that enables module Y would solve the problem.

0

I solve this problem by creating a custom .install file for my feature module, and implement hook_enable(). You can enable each dependency via something along the lines of:

if (!module_exists('dependency')) {
  module_enable(array('dependency'));
}

I've also used this method to enable new dependencies via hook_update_N()

0

Try doing drush rq and implement hook_requirements:

function MODULE_requirements($phase){
    if($phase != 'install'){
        $module_info = drupal_parse_info_file(drupal_get_path('module', 'MODULE').'/MODULE.info');
        $dependencies = $module_info['dependencies'];

        $enable = module_enable($dependencies);
        if(!$enable){
            throw new Exception('Unresolved dependencies', 1);
        }
    }

    return array();
}

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.