[development] Installation -- Can A Module "Refuse" To
adrian at bryght.com
Mon Apr 10 20:26:30 UTC 2006
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
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
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.
want to enable all the dependencies, so you don't have to do it in
multiple phases if you
> I'd like to see development on this move forward as a patch to
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
> 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
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
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 developer and Bryght Guy
http://drupal.org | http://bryght.com
More information about the development