Score:0

How to Install new module, add code to existing module that requires the new module, and import config for the new module in the same build

hk flag

I seem to be running into a circular dependency issue in the scenario where my new build has a new module (B), new code in an existing module (A) that depends on the new module (B) and new config being imported for the new module (B).

In the past I have handled this with creating and deploying two independent builds, one where I deploy the new modules and enable them, and in the second build, deploy code that requires the new modules and the config for the new modules.

Is there a better way to handle this?

The change in Module A is that one of the services in Module A requires a service from Module B.

I have already added dependency to the new module B in module_A.info.yml file but that does not help as the module is already installed.

drush en module_b does not work and it gives the error.

The service "module_A_service" has a dependency on a non-existent service "module_B_service".

The config import that is in the build has core.extensions updated to enable module_B when it is imported but config import with drush cim is failing with the same error as above.

id flag
I have done what you have done. You can also think about detecting the other module or service and falling back onto some basic behavior.
cn flag
It sounds like you want to add a `hook_update_N` in module_A to install module_B
hk flag
Thanks for the responses @cilefen Aren't service dependencies kind of hard in the way the dependencies are added in the yml files?
hk flag
Thanks for the response @Clive - I didn't explicitly try that, but I tried a drush php eval of \Drupal::service('module_installer')->install(['module_b']);. That gave the same error. Would it behave differently in hook_update. I could try that as well.
Jaypan avatar
de flag
The error indicates that your A service has a dependency that does not exist, which is not a circular dependency. What is the error if you deploy everything in one commit, rather than splitting it into two?
hk flag
Thanks for your reply @Jaypan. drush cr fails with the above error. drush cim also fails with the same error. drush updb runs but shows the same error. I am not deploying this in multiple builds. I am deploying in a single build. What I was saying was that I usually address this issue with two builds and was trying to figure out what would be a good way to address this in one single build.
Jaypan avatar
de flag
If this is from a single deploy, try using Drush to enable Module B first, then run `drush updb`.
hk flag
drush en module_b was failing with the same error as above. However I went ahead and added a hook update with the \Drupal::service('module_installer')->install(['module_b']); like what @Clive suggested. It went through without errors and installed the module. So the solution is to add a hook update to explicitly enable the dependent module even though the build has the config to enable the module later.
cn flag
I think `updb` does run under a different bootstrap mode so it's worth a shot if you're able to test first (just pulling DB/public files down and running locally should let you do that). I'm pretty sure I've done exactly this before to solve the same problem. Maybe don't do a `drush cr` before the `updb`, so the system doesn't get a chance to rebuild the plugin cache until the module is enabled
hk flag
Thanks @Clive. That did the trick.
Score:1
hk flag

This is the solution that worked

a) Implement a hook_update_N in module A that is already installed. In the hook_update_N add code to install module_b. Include this in the same build.

function module_a_update_NNNN(&$sandbox) {
  $module_installer = \Drupal::service('module_installer');
  $module_handler = \Drupal::service('module_handler');
  if (!$module_handler->moduleExists('module_b')) {
    $module_installer->install(['module_b']);
  }
}

b) Deploy the build

c) Do not clear cache. If you run cache clear before updb it will throw the same error as mentioned in the question.

d) Run drush updb

e) Run drush cim

f) Run drush cr

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.