[development] 4.8/5.0: Modules, the install system, and directories

[Greg Knaddison]

On 2/22/06, Morbus Iff <morbus at 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