<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><BR><DIV><DIV>On 11 Nov 2007, at 9:23 AM, Karoly Negyesi wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite"><P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">Gerhard asked this in the current kitchen sink thread and the answer</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">is IMO obvious: the package script is missing so that instead of a</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">bare profile you can download a tarball. Who wants to work on this?</FONT></P> </BLOCKQUOTE></DIV><BR><DIV>I've been putting a considerable amount of thought into this recently (as I'm developing a considerably complex install profile at present),</DIV><DIV>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, </DIV><DIV>we inevitably need some form of memory resident code.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>The only way to bypass this at the moment, is to ship a _support module along with it. This is not ideal. Essentially, install</DIV><DIV>profiles are like trying to write a module using only the .install file. You can't really accomplish much with those limitations.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>What I suggest, is that we bypass this limitation, move what we currently call a .profile to a .install, and turn the inevitable </DIV><DIV>_support module into the .profile. This should still imo be stored in profiles/</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>A simple modification to the loading code will allow us to ALWAYS include the profile in the module_list and loading (I think</DIV><DIV>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</DIV><DIV>and themes, and then that allows us to much more easily write the package generation scripts.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I'm not really convinced profile_final is necessary, as an _install hook could accomplish exactly the same thing, with the added benefit</DIV><DIV>that we get NUMBERED SCHEMAS, which is a major drawback in our current system.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>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</DIV><DIV>without the current numbered schemas. it's frighteningly difficult actually)</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>What I think works better in this case, is the $module_default_$things functions (example : hook_views_default_views), that provide</DIV><DIV>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</DIV><DIV>quite hacky).</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I would also resurrect this patch of mine <A href="http://drupal.org/node/25745">http://drupal.org/node/25745</A>, which I actually need to do regardless. But what that would do, is</DIV><DIV>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)</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>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 </DIV><DIV>major added benefit we have, is documentation / education. If you can write a module, you can write an install profile.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>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</DIV><DIV>make these profiles useful.</DIV></BODY></HTML>