Out-of-date dependency processing in panopoly_core

Which ones show as problems? The "project:module" syntax for dependencies has been around for a few years. What version of Drupal are you using?

The module's dependencies were changed in #2844504: Testbot failing for Metatag-D7 =) and Drupal core was updated to support this structure in 7.40 which was released in October 2015. So yeah, you need to update your core release.

Remember that when you run into a problem with a module you should always make sure your system is up to date across the board.

This patch updates the requirements to specifically note 7.40 is required.

FYI I updated the 7.21 release notes to point this out: https://www.drupal.org/project/metatag/releases/7.x-1.21

Committed.

Apologies for the mixup, I should have noted in the release notes and updated the module's requirements.

I'm installing a new site with Metatag as a dependency, and whenever I use 7.x-1.21 I receive the following error on the Verify requirements step, and am unable to proceed without dropping Metatag down to 7.x-1.20 or lower. For my install, I'm using a custom installation profile based on the Panopoly distribution, and have the profile configured to use the latest non-dev release of Drupal 7 rather than a specific version.

Required modules	Required modules not found.
The following modules are required but were not found. Move them into the appropriate modules subdirectory, such as sites/all/modules. Missing modules: Ctools:ctools, Token:token, Metatag:metatag, Metatag:metatag_dc, Panels:panels, Views:views

I can see from the other comments that this is a new syntax starting from 7.40 and up, but does that work with installation profiles? If not, should this issue be re-opened, or should it be handled as a core issue?

Yeah, I can reproduce this with the following change to panopoly:

diff --git a/panopoly.info b/panopoly.info
index 2ee445e..2752de7 100644
--- a/panopoly.info
+++ b/panopoly.info
@@ -21,6 +21,8 @@ dependencies[] = file
 dependencies[] = dblog
 dependencies[] = update
 
+dependencies[] = metatag
+
 ; Panopoly Foundation
 dependencies[] = panopoly_core
 dependencies[] = panopoly_images

I opened a core issue: #2855026: Installation profiles do not support project:module format for dependencies

Marking this postponed until the core issue is fixed.

I've worked out a fix in #2855026: Installation profiles do not support project:module format for dependencies, now to work with the core team to make it commit-worthy.

I can’t reproduce the issue as described with Drupal 7.56. According to my tests in #2905520: Installation profiles do not support project:module format for dependencies (backport to D7) it seems that the profile.info is not allowed to have project:module dependencies or versioned dependencies, but depending on a module that has such dependencies is not an issue.

Ha, when I download panopoly like mentioned above I can reproduce this issue. I just can’t reproduce it with any other installation profile. So this seems to be something specific for panopoly. Perhaps they somehow "inline" the nested dependencies?

Ok, the problem lies in panopoly_core_install_load_profile(). It indeed inlines all the module dependencies and does it without support for project:module format dependencies.

This is not an issue with metatag.

Moved back to the Metatag issue queue as this is a problem with Metatag that unearthed a bug in core; feel free to open a new issue in the Panopoly issue queue if you need, but please don't hijack this one.

@Damien Please read the evidence before you draw conclusions.

1. The bug is not reproducible in any other installation profile.
2. If you remove the function panopoly_core_install_load_profile() from panopoly the installation works fine.

I’m not saying core doesn’t have an issue (namely that installation profiles can’t have complex dependencies directly) but what caused the error in this bug report and what hinders metatag from using new-style dependencies is not a bug in core but a bug in panopoly.

Edit: And yes perhaps fixing the core limitation would fix the panopoly bug too … but until then panopoly should take care of core’s limitations and do the same thing that it already does for versioned dependencies: cut them out before injecting them into the profile installation process.

Here is the copy of the function so you can see yourself:

/**
 * Task handler to load our install profile and enhance the dependency information
 */
function panopoly_core_install_load_profile(&$install_state) {

  // Loading the install profile normally
  install_load_profile($install_state);

  // Include any dependencies that we might have missed...
  $dependencies = $install_state['profile_info']['dependencies'];
  foreach ($dependencies as $module) {
    $module_info = drupal_parse_info_file(drupal_get_path('module', $module) . '/' . $module . '.info');
    if (!empty($module_info['dependencies'])) {
      foreach ($module_info['dependencies'] as $dependency) {
        $parts = explode(' (', $dependency, 2);
        $dependencies[] = array_shift($parts);
      }
    }
  }
  $install_state['profile_info']['dependencies'] = array_unique($dependencies);
}

@torotil: Please open a new issue and cross-reference it, and do not hijack issues.

Yeah that’s a matter of interpretation and I see you have another interpretation than I. I just spent a few hours tracking this down. ;-)

Never mind. I don’t use Panopoly and I don’t need this bug fixed. Good luck!

@torotil: My sincerest apologies, I was in a hurry earlier and didn't think Panopoly had anything to do with it as I'd forgotten that my own testing was based on Panopoly.

I've reviewed the code you reference and yes, the problem is in Panopoly after all.

Moving this back to the Panopoly issue queue and attaching a patch which may resolve the problem.

Again, I am sorry for my response.

@damien Np. Great to hear that we seem to be on the same side now.

Is there a reason why you avoid using drupal_parse_dependency() in your patch?

I forgot it was there? :)

Here is a new patch using drupal_parse_dependency().

The patch still doesn’t allow complex dependencies in the installation profile itself on purpose: The most promising patch for allowing complex dependencies in install profiles would make this whole function obsolete.

Thanks, @torotil & @DamienMcKenna!

Trying the tests on Travis with the patch:

https://travis-ci.org/panopoly/panopoly/builds/337598643

Hi all, just reporting that the patch at #29 solved the problem in my case.

I haven't tested this, but the patch looks good to me. Marking as RTBC so it doesn't get lost :-)

Committed! Thanks, Everyone!