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.