In my recent project I created a feature which depends on the media module and the media_gallery module. The media_gallery module has some version numbers in their dependency list. After creating the feature it gives me the message 'Unmet dependencies: media (1.0-beta5), multiform (1.0-beta2)'.
Adding version numbers to met a dependency is discouraged but allowed in D7 (http://drupal.org/node/542202).
So I think this is missing in features module.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | features-1219932-3.patch | 949 bytes | febbraro |
| #2 | features_module_versions.patch | 1.19 KB | acrollet |
Comments
Comment #1
t-dub commentedI'm experiencing the same problem (on 7.x-1.x-dev). I dug through the code a bit, but I'm not grokking it well enough to solve the problem.
Here is what I have so far:
It seems to be only in the admin form (
features_admin_form()) that this faulty check is made since enabling the module directly via drush or the modules page doesn't result in errors.The core of the problem appears to be that Features is expecting
system_rebuild_module_data()to only have module names in the returned dependencies array and insteadsystem_rebuild_module_data()includes the entire dependency string. So that means that either infeatures_get_info(),_features_export_maximize_dependencies()orfeatures_admin_form()(to trace back the major steps along the code path), the optional version information must get parsed out prior to doing comparison of installed modules against dependent ones.What confuses me is that as part of what happens in
system_rebuild_module_data(), it seems as thoughdrupal_parse_dependency()should be called, which would result in the dependency being split into its name, operation, and version. But when I take a look at what's coming back fromsystem_rebuild_module_data(), it's very clear that this has not happened. Obviously it's not a core bug because dependencies work as expected elsewhere, so I'm just not reading something right. Up until that point, though, I'm pretty confident that I've understood what's happening.I can't make any more progress on this right now but perhaps this will help someone else (or me if I come back to it).
Comment #2
acrollet commentedThe attached patch deals with this issue. The only problem it has is not detecting if an incompatible dependent module is present. Since it seems that Features has never had this functionality, I don't think this is a deal-breaker...
Comment #3
febbraro commentedThat patch did not fix it, so I rerolled to address it correctly, please test it out and let me know.
Comment #4
febbraro commentedTo clarify, the patch in #2 worked if a direct dependencies dependency contained the version number, but not if you added a dependency w/ version directly to the feature's .info file. A slight rework but more robust.
Comment #5
febbraro commentedFound 2 other places where this was a problem. Should be all fixed now, thanks.
http://drupalcode.org/project/features.git/commit/d5a4441