[development] Installation profiles: here is what missing

[adrian rossouw]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20071111/c0fdceda/attachment.htm