On 11 Nov 2007, at 9:23 AM, Karoly Negyesi wrote:

Gerhard asked this in the current kitchen sink thread and the answer

is IMO obvious: the package script is missing so that instead of a

bare profile you can download a tarball. Who wants to work on this?

I've been putting a considerable amount of thought into this recently (as I'm developing a considerably complex install profile at present),

and I've considered that one of the largest obstacles with actually writing an install profile, is that for almost any thing we need to accomplish,

we inevitably need some form of memory resident code.

The only way to bypass this at the moment, is to ship a _support module along with it. This is not ideal. Essentially, install

profiles are like trying to write a module using only the .install file. You can't really accomplish much with those limitations.

What I suggest, is that we bypass this limitation, move what we currently call a .profile to a .install, and turn the inevitable

_support module into the .profile. This should still imo be stored in profiles/

A simple modification to the loading code will allow us to ALWAYS include the profile in the module_list and loading (I think

last in the chain is the best place to put it). We now have the ability to use the already existing .info management code for modules

and themes, and then that allows us to much more easily write the package generation scripts.

I'm not really convinced profile_final is necessary, as an _install hook could accomplish exactly the same thing, with the added benefit

that we get NUMBERED SCHEMAS, which is a major drawback in our current system.

While we could use CRUD to create a lot of the object we need to run the sites, it's not quite as manageable in the long term (especially

without the current numbered schemas. it's frighteningly difficult actually)

What I think works better in this case, is the $module_default_$things functions (example : hook_views_default_views), that provide

the default data object. According to eaton, cck v2 will have this feature as well (cck + install profiles don't really mix well atm, cck_import is

quite hacky).

I would also resurrect this patch of mine http://drupal.org/node/25745, which I actually need to do regardless. But what that would do, is

allow the developer to specify $default variables in the same was as the $conf overrides (possibly in the _init hook which the profile now gets)

Quite possible we would end up reducing code in this process, by getting rid of most of the special handling of install profiles, and a

major added benefit we have, is documentation / education. If you can write a module, you can write an install profile.

I'm not just suggesting this, I'm actually going to be working on patches to this effect in drupal 7, because I really believe we need to

make these profiles useful.