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

[Earl Miles]

Morbus Iff wrote:
> 
> This is what I'd like to see in 4.8/5.0 which would tie up some "loose 
> ends" as it were with some of the direction that Drupal is moving in. 
> These are bullet points because I'm heading off to work, but I'll be 
> more than happy to wax further.
> 
>  * Modules get their own directory. (modules/system/system.module).

Sounds reasonable to me. I think certain things get a little messy but it does 
help the install system and it becomes a lot easier for modules to dump 
less-used functions off into *.inc files.

>  * All modules get own .install (modules/comments/comment.install).
>    This way, all the relevant tables of a module are "closest" to the
>    source, and won't actually get thrown into the db until someone
>    enables them (I hate the fact that I've got about 15 tables I'm
>    not using in my Drupal database. Just drives me nuts.) This also
>    helps update.php in that it will only need to go through ENABLED
>    modules, instead of performing updates for unused tables. We can
>    also pre-create/publish nid 1 in modules/node/node.install without
>    having that dummy hardcoded text, a long standing issue.

I think this is a good idea.

>  * databases/ directory is removed entirely. By giving each module
>    their own .install, we don't really need databases/ anymore -
>    we'd just need to, at first run, check if table system exists.
>    If not, find all required modules and run their .install. This
>    way, we remove the entire schema creation step of the INSTALL.
>    All the existing updates.inc would move into system.install.
>    This is nice, IMO, because it'll make a purdy friendly installer
>    a lot easier to create (as it'd just have to send to the frontpage
>    after DB config/QA instead of sucking in databases.mysql).

This also makes a lot of sense.

>  * Modules get an activate, deactivate, and uninstall hook. I think
>    Merlin was working on this to some degree. Activate enables the
>    module, deactivate disables it, but keeps the created data, prefs,
>    and tables in place, and uninstall removes everything. This mimicks
>    the operation of Gallery 2 modules - the uninstall part is awesome!
>    If I use search.module for a week on my 5000+ node site, then find
>    out it's just not good enough, I don't want those gigantic tables
>    hanging around forever, taking up backup space. If I uninstall
>    search.module, those tables and data should be removed.

I particularly like this combination.

>  * .install files get aggregator_schema_version() function which tells
>    the installer which version number to set in the system table on
>    FIRST INSTALL. This way, it's not calling or seeing a number of
>    updates that are already applied to the initial starting table.
>    (I think this is a problem in our current install system, right?)

This is probably unnecessary as has already been said.

>  * By putting modules into their own directory, we're making it easier
>    for some of those comments.help related ideas to kick in - to stick
>    the help text in an external file and call it only when needed. I
>    also think that chx's splitmode is a lot nicer if we could constrain
>    the split functions to their source directory instead of having a
>    primary directory full of 1000+ mini-files.

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.