[development] 4.8/5.0: Modules, the install system,
merlin at logrus.com
Wed Feb 22 15:12:48 UTC 2006
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.
More information about the development