[development] Installation profiles: here is what missing

[Simon Hobbs]

Adrian

You've identified a major issue for me. If my goal is to make happy
with the usability, I can't seem to escape having a supporting module.
I really appreciate the razor you've applied to this problem! I'm with
you on this.

An added benefit of the profile being active after install (based on
my D5 experience here) is the ability to have a wizard.

.s


On Nov 11, 2007 11:00 PM, adrian rossouw <adrian at bryght.com> wrote:
>
>
>
>
> 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.