[development] Installation -- Can A Module "Refuse" To Be Installed?

[Adrian Rossouw]

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