On 2/22/06, Morbus Iff <morbus@disobey.com> wrote:
The one thing missing is that modules should be able to declare what other modules need to be enabled. I think I agree with Steven's basic premise that we don't want to auto-activate modules unless the operator says it's ok, so in my ideal world I'd come back with a list of modules that need to be activated and say "activate all these modules too?" kind of like yum does. I assume apt does roughly the same thing.
I think that's too much workflow:
* user clicks checkbox. * user clicks submit. * user gets message listing pre-reqs. * user clicks all pre-reqs. * user clicks submit. * user gets more pre-req messages.
I'd much rather see the pre-req's listed in the description:
name | description (requires: comments) | [] []
Then when the user clicks the box, we *can* enable the pre-reqs without further user intervention, because we can assume he saw the required components part of the description, and still wants to continue.
That is actually more of how yum/apt solve the problem (for those familiar with the analogy). User: command to install package X System: recursively check dependencies and dependencies of dependencies, and list any packages that need to be installed to satisfy dependencies with a "y/n" option to the user to install those packages - it also checks that the version numbers are correct in each of the dependencies. User: says "y/n" System: do stuff I'm not sure if Drupal needs the whole version number system. In the case of yum and firefox (two other packages I'm familiar with that make heavy use of external "modules") they both track API compatability and provide an API version number in the core package. Modules provide version number(s) that they are capable of working with - if the two sets don't intersect then the system does not let the module get installed. Users who feel like living dangerously can edit the module's internal XML that stores the range of compatable core versions and try installing again - but this frequently fails and leads to a sad user who can only blame themself. This system would shift support requests from "why does this 4.6 module not work when I install it on a 4.7 sysem" to "why won't Drupal let me install this 4.6 module in a 4.7 system". I think the latter question is easier for the user to answer on their own and then understand better how the system works. It has pretty clear benefits to users, but also makes for a slight increase in administration cost and a slight increase in the code base. Basically, in addition to using an unenforced CVS branch to mark which core-version a particular module is compatable with, we also use and check a version in a file in the module. Regards, Greg