Problem/Motivation

Let's assume the following scenario:

  • just system module is installed
  • install module A, that depends on module B and module B module using ModuleInstallerInterface::install(['module_a', 'module_b'])
  • Module A uses the module B module in their services.yml file

It crashes ...

The problem is that module installer, while installing all dependencies when you just specify module_a, it doesn't put the installed modules into the right order.

Proposed resolution

Build a graph of dependencies we want to install and sort is properly

Remaining tasks

User interface changes

API changes

Data model changes

CommentFileSizeAuthor
#4 2712419-4.patch3.01 KBdawehner

Comments

dawehner created an issue. See original summary.

larowlan’s picture

larowlan
Location 🇦🇺🏝.au GMT+10
commented

We should consider back port to d7. This has always caught me out, especially in install profiles and tests

dawehner’s picture

dawehner
Primary language German
commented
Assigned: Unassigned » dawehner

I'll have a look at that

dawehner’s picture

dawehner
Primary language German
commented
Assigned: dawehner » Unassigned
StatusFileSize
new 2712419-4.patch3.01 KB

While trying to write a test for it, see patch, I realized there is something in ModuleHandler::buildDependencies which should deal with that.

larowlan’s picture

larowlan
Location 🇦🇺🏝.au GMT+10
commented
Status: Active » Needs review

So RTBC if green?

Status: Needs review » Needs work

The last submitted patch, 4: 2712419-4.patch, failed testing.

dawehner’s picture

dawehner
Primary language German
commented

Well, when I worked on #2687897: Convert system module's kernel tests to NG it somehow didn't took that properly into account.

larowlan’s picture

larowlan
Location 🇦🇺🏝.au GMT+10
commented

From memory this only manifests in tests, which would point to the enabling stuff in the setup/init.

We had a script to make sure the order of dependencies in our profile .info files in d7 was in dependency order, else the installation from a profile in the test had weird results

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

quietone’s picture

quietone commented
Status: Needs work » Needs review
Issue tags: +Bug Smash Initiative

Is this still a problem? It looks to me that the installer does use \Drupal\Core\Extension\ModuleHandlerInterface::buildModuleDependencies.

There is an existing test of installing two modules with a parent/child relationship, \Drupal\KernelTests\Core\Extension\ModuleInstallerTest::testConfigChangeOnInstall whereas the test here is with two sibling modules where one depends on the other. Should we add this test?

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

quietone’s picture

quietone commented
Status: Needs review » Closed (outdated)

I reviewed this again today and I think I was wrong, this isn't testing siblings. The test of ordering is in testConfigChangeOnInstall which was added in 8.4.x in #2679008: Module weight is not taken into account after module installation.

Therefore, closing as outdated. If this is incorrect reopen the issue, by setting the status to 'Active', and add a comment explaining what still needs to be done.

Thanks!