Checking/resolving new dependencies for updated modules

There are some pages in core - admin/modules is one, where we already call system_rebuild_module_data(), and there's a pending patch to add a static cache for that, so it only runs once per page. So when that static cache is in, adding it to pages which already run that check ought to have minimal performance impact. However it gets really, really expensive when you have lots of modules (c9... measured around 4 seconds) so adding it to pages where it's not already I'd really want to avoid.

For unmet dependencies, for D7 I don't think we can do more than warn. There's an issue to add a recovery.php somewhere, and it's also been discussed adding some of that wsod recovery to the update manager since that's already a minimally bootstrapped environment where you can affect your installation.

As Jacob Singh brought up in #228860: Upgrading a module with a newly added dependencies breaks things badly an unmet dependency can completely kill your site if the module implements a class of the missing module.
Hence, I don't think the performance impact is worth it, because we are only catering for people, who:

1. Don't visit update.php after uploading a new version of a module. (which we discourage, anyway, as stated above)
2. Have the luck of uploading a module which doesn't implement a class of a newly added dependency. (which we have absolutely no control over)

Regarding the second point mentioned in the OP, on update.php on the 'Verify Requirements' page, where the error is shown, if there is an unmet dependency, it should give the option to enable the dependency (if it is available) or disable the depending module. That way, if you simply forgot to install the new module you can do so (or first download it and then do so), or if you are not sure, whether you actually want to install the dependency on your site (for whatever reason), you can disable the module that requires it, if you know that disabling that module is not going to eat your site.

Here's how it could look.

Tagging.
The strings in the screenshots are:

@module1 requires this module. You can either install @module2 or disable @module1 module.

@module1 requires this module. You can either install @module2 or disable @module1 module.

Do you really want to install @module2 module?

Do you really want to disable @module1 module?

It appears that installation profiles are (unnecessarily?) being considered as modules in regards to dependency checking. I made a new install with the "Standard" install profile, then disabled the Overlay module. I then used CVS to update a contrib module and went to run update.php, but got hit with this error: "Unresolved dependency - Overlay (Disabled) - Standard requires this module." If I re-enable Overlay, I can then run update.php as normal. Lame! Especially considering how I usually disable Color and Comment as well. Is there a particular reason we can't exclude installation profiles from this dependency checking, at least as far as update.php is concerned?

@Garrett

We split that install profile issue off over here --> #808162: update.php fails when optional modules disabled

This is especially problematic when the added dependency is required by a hook_init() implementation. It's very easy to WSOD a site that way. In my modules, I've had to add code like

if (!module_enabled('dependency_module')) {
  module_disable(array('this_module'));
  drupal_set_message('BIG FAT WARNING');
  drupal_goto('admin/modules');
}

Plagiarizing the excellent summary by KarenS:

A module may add a new dependency -- which could be a dependency on another module, a requirement for a higher version of PHP, or a later version of a previously required module. If the new dependency is not met, it creates several additional problems:

1. If the module it is dependent on is not enabled, the checkbox to enable it cannot be checked on the modules page, it is an empty, disabled checkbox.
2. The missing dependency makes it dangerous to run updates.
3. The missing dependency may create fatal errors which make it impossible to get to the modules page to enable the required module.
4. The required module may be missing, so there may be no way to enable it.
5. A D6 -> D7 upgrade creates additional problems because you can't get to the modules page to manually enable newly required modules until at least the core updates have run, but if you run update.php to update core you will also update modules with missing dependencies.
6. In all cases, the administrator should be warned that a dangerous instability exists.

The patch in this issue addresses (1) and (2) and partially addresses (6) -- it does not warn the administrator unless they go to update.php.

Note that the referenced patch has been committed, so only #3-5 and part of #6 are still unresolved.

Seems like a useful improvement, can this get a update?

I have just released Textimage 8.x-3.0-alpha2. In this release I added a dependency to the image_effects module. Updating from Textimage 8.x-3.0-alpha1 (which did not have the module dependency), it looks like there is no check on the newly added dependency. So I end up trying to use Textimage functionalities without the image_effects module installed, and get fatal errors :(

If I uninstall Textimage and try to reinstall, everything works - the installer finds the dependency, proposes to install image_effects too, and confirming I get both modules installed.

Steps to reproduce:

• Install Textimage 8.x-3.0-alpha1, configure it, create an Image Style using the Textimage Text image effect
• Check for available updates (Manage>Reports>Available Updates), ensure the check is fresh, it should say there's alpha2 available
• Update to alpha2 through the update process
• Edit the Image Style created at the beginning, fatal error

So this is definitely major, but I don't think it's critical. In stable contrib releases, a new dependency should mean a new branch for that module and have a prominent mention in the release notes, and there should be a hook_update_N() to install the dependency.

Or there are other ways to mitigate it like provide a temporary compatibility layer for the new dependency and warn people they need to update it in an interim release - so at least they can go pre-depencency -> compat version -> no-compat.

But in terms of what core can do, if you have code that has a hard dependency on code that's not there, and that code is in the critical path of a Drupal site, Drupal itself isn't going to be able to do much to resolve it. Possibly rebuild.php could detect the missing dependency and warn loudly?

Using features module for a configuration management approach, depends on changing module dependencies to work in a lot of scenario's. Related: https://www.drupal.org/node/2726839

Attached patch highlights this problem on the /admin/modules page.