Follow-up from #211747: Allow specifying version information as part of module dependencies...
Once that patch lands, there's some somewhat tricky logic to test if a given module's version dependencies are met. It's currently baked directly into system_modules(). It'd be nice to refactor that into a separate function so that it could be shared and reused in other places. It'd also be easier to write unit tests as a stand-alone function. I haven't thought about exactly what the function signature should look like, nor if it should live in includes/modules.inc or modules/system/system.module.
Comment | File | Size | Author |
---|---|---|---|
#13 | 533586-13.module_dependency_refactor.patch | 9.43 KB | dww |
#10 | 533586-10.module_dependency_refactor.patch | 9.41 KB | dww |
#8 | 533586-8.module_dependency_refactor.patch | 8.87 KB | dww |
#4 | refactor.patch | 8.52 KB | chx |
Comments
Comment #1
dwwObvious use-case in core for sharing: #540952: Specify version dependencies for base themes
Comment #2
mikey_p CreditAttribution: mikey_p commentedI'd suggest something like this (pseudo code), (no idea what to call it)
Also on the list, perhaps, moving the parsing out of _module_build_dependencies(), so that it can be reused for themes?
Comment #3
dwwYup, parsing also needs to move for this to be useful...
Comment #4
chx CreditAttribution: chx commentedRefactored. Allowed me to move back the two other (enabled, disabled) messages to the same level. might be curious to use module_check_incompatibility instead of compatibility but that's what I needed. Also, simplified: removed the preg, now we check everything with version_compare. Sometimes two, but still, the code is simpler. It works.
Comment #5
mikey_p CreditAttribution: mikey_p commentedLooks great.
Comment #6
Dries CreditAttribution: Dries commentedI don't fully understand the return value of module_parse_dependency(). Why is the original value returned at all? I'd change that as it would make for a more predictable and consistent API.
The PHPdoc doesn't properly explain what is returned. Maybe you can include an example?
Comment #7
chx CreditAttribution: chx commentedAlthough that structure is documented, it does not matter at all. You pass the structure on to module_check_incompatibility and that's it.
Comment #8
dwwOverhauled the PHPDoc. Otherwise untouched.
My only lingering concern about this patch is that I want to use it for #540952: Specify version dependencies for base themes, and it seems slightly weird for themes to be calling functions named module_parse_dependency() and module_check_incompatibility(). Would it be better to move these functions to includes/common.inc and call them "drupal_*" instead?
Comment #9
dwwOh, just looked more closely at the code. ;) Why does module_parse_dependency() take a reference to $dependency? That should either be removed or documented. Looking at the code, it doesn't seem necessary, and we should probably just remove it, but I'll let chx answer before I do.
Comment #10
dwwFound chx in IRC. He wanted $dependency by reference so that a side effect of calling this function is to convert your dependency from "foo (>=7.x)" to just "foo". Yuck. So, now the function includes a 'name' field in the returned associative array, and callers that want just this part can inspect that. Also, he agreed with the move to includes/common.inc and s/module/drupal/ in the function names.
What say 'ye, bot?
Comment #11
chx CreditAttribution: chx commentedWell, sure. Cleaner a bit, I guess.
Comment #13
dwwSorry about that. PHP notices from just testing $v not $v['versions'] in drupal_check_incompatibility().
Comment #14
chx CreditAttribution: chx commentedYes because you added a 'name' key to my otherwise nice and empty array. Anyways, dww happy, the bot is happy and I am OK too.
Comment #15
webchickSince documentation of the return value is all Dries pointed out above (curiously, not also the wtf-inducing "$v" as a parameter in a public function), and the documentation looks good, I committed this to HEAD.