I have taken over control of the dependencies module, and will be putting the code together, in contrib (god bless _form_alter) to handle the dependency checking / metadata loading. Really, a good chunk of this is ready and tested, it's just assembling it in one place. Before 4.7 and the forms API, this meant modifying system.module, but that is not the case anymore. This will become a patch for system.module, but not until the 4.8 branch is available, additionally a lot of people want to use this today (see: ecommerce) I've already discussed with Jeremy the possibility of including this with the civicspace installer build, so we can get a good amount of testing for it, perhaps even a semi-official uptake of the meta-info files in contrib during 4.7. Vlado has a script which generates meta-data files for all the modules in contrib, but they do need some hand tweaking however, so moving to using meta-data isn't even going to be that hard. On 10 Apr 2006, at 8:02 PM, Neil Drumm wrote:
- That would create another line on an already long .../admin/ modules page which most people will simply not want to care about. Of course not. This is just to get the code developed, and deployed, so we can get it fast tracked into 4.8 when it opens.
- I fear layering on the formapi extensibility will make code more fragile (what happens when two modules try modifying the same elements) and harder to understand. It's a means to an end, and it's really just additional validation on a form. That's why we have the possibility of multiple validation hooks in the first place.
I would like to have it be as non-obtrusive as possible. Perhaps even just failing validation of the form, and adding a new checkbox to the top saying 'the following modules were required, would you like to enable them too?'. or a message stating that the module couldn't be enabled as the required modules weren't found. Perhaps even do a little bit of javascript that asks you whether you want to enable all the dependencies, so you don't have to do it in multiple phases if you miss something.
I'd like to see development on this move forward as a patch to system.module. That's definitely the plan. The meta-data info could also be used to build the admin/modules screen to stop memory problems, for instance.
We can look at these more serious architectural changes for the next release.
What might be "holding back" core dependencies Nothing. Except no 4.8 branch, and stuff (like ecommerce) really needing it today.
The potential problem I see is the potential for intricate dependency trees between contrib modules and putting users in dependency hell. Imagine what would happen if each ecommerce module were in its own directory and a dependency system was relied upon. Intricate dependency trees likely already exist between contrib modules, except apart from help text, we have no way of documenting or checking it.
Being able to mark conflicting modules, and the like would also be very useful. And the modules can be in a tree, or in their own directories, but thanks to the great equaliser of system_listing, it's all a flat list to us. if we are talking about packaging them separately, that's a discussion we should have at a later stage, when we have a working simple dependency system with well tested version checking, INCLUDING having chosen a standard format for individual package versioning (http:// drupal.org/node/58066) -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com