Allow more control for install profiles: override full task list

I'd personally prefer something like the attached - it seems to me like having a hook_install_tasks_alter() functionality is both simpler and more flexible.

This still allows profiles to override the whole list of installation tasks if they want to, but it also preserves a simple way for them to add to or slightly alter the list, which I think is much more common.

OK, and here is a version of the patch that actually works :) The "hook" gets called too early to guarantee that the profile file is always loaded, so we have to explicitly load it.

I didn't create a whole profile to test this, but the code is sane.

The original patch is optimized for someone who wants to replace Drupal's entire array of installation tasks, which is extremely rare. Everyone else would essentially have to implement their own "alter" method anyway, by calling install_default_tasks(), modifying it, and returning it as their own. In addition, the most common use case (someone who simply wanted to add a new page into the installer, which core currently supports via a very simple method) would require splicing the array and figure out how to insert their task in at the right place. I think this makes things more complex for profile authors.

I don't think adding another hook is a problem -- the pattern of using one hook to add your stuff and another hook to modify other people's stuff is very common in Drupal. Plus this is for install profiles only (and complicated profiles at that) so it's a hook that almost no one will need to worry about. Possibly for consistency, however, instead of having hook_profile_tasks() and hook_install_tasks_alter(), it would be better to modify my patch to make these more similar; e.g., hook_install_tasks() and hook_install_tasks_alter()?

Also, either of these patches probably requires some updates to the hook documentation in system.api.php, but hopefully that could be saved for a followup patch.

Looks like this still needs discussion..?

Fixing tag

what i have against these patches is that it could make it harder to automate installs.

I'll review this patch properly a bit later

This kind of feature would be really useful to implement a profile integrating with the new localize.drupal.org service. Since integration on both ends will not be ready on time for the Drupal 7 code freeze, we only have the install profile option. So making that capable of being aligned would be highly useful.

I am adding this here for context, as this was what brought up this issue to begin with.

Hi Adrian, David,

Since you have been working heroic hours on the install profiles and
got them to a pretty nice state, I figured I'd ask your opinion first
and maybe your help even in fixing this missing piece before code
freeze.

The story is that we are in private beta testing of
localize.drupal.org which is soon to open to public beta testing.
There language teams are set up, d.o project releases are
automatically parsed for translatable strings and teams can translate.
Now the best for Drupal would be to pull the list of available
languages from there if an internet connection is available on install
and then download the latest translations from there again on
installation. since the infrastructure for the language listing and
downloads/updates is not in place, this is not realistic in the D7
code freeze timeframe.

So I'm thinking install profiles of course. We'd need a way to
override the install.php language selection way, so that it displays a
list of languages pulled from remotely. So the Choose language step
would be there but overridden. This looks like maybe being possible
with form altering on install_select_locale_form. What do you think
and are you aware of any changes which would be required to implement
this? Unfortunately I was most busy with setting up the other end of
the infrastructure on localize.drupal.org, so did not yet have time to
look deeply into this.

Thanks a bunch,
Gábor

I don't have a particular fish to fry here (since I doubt that I personally will ever need to use this feature), but this is technically an API change, and it seems like we have a clear use case, plus some simple working code. Does someone want to help push this in before the code freeze? :)

Regarding @adrian's comment, it's already possible to write an install profile that would fail to work with a (generic) automated installer - this would just give a new avenue for doing so. The main issue where that would hurt is #525594: Installation should consist of 2 phases instead of one, but there's no code there yet, so I think this is probably a concern that wouldn't really come up until Drupal 8?

Agreed. This is RTBC.

OK, but we should definitely change the hook names to be consistent, and update the system.api.php docs as well.

This one should be RTBC.

Looks good to me, agreed.

Sorry, thought I'd committed this a long time ago. It pays to glance through the RTBC queue from the back sometimes. :D

This is the final piece in de-WTFIng install profiles. Happily committed to HEAD.

I don't think the concern of "too many hooks" really applies during installation. We're firing... what? Maybe half a dozen hooks at the most there? Gábor's use case is a solid one for this functionality, and I've seen a few myself through the years of writing install profiles as well, but opted for sub-optimal hacks like form_altering in stuff to an already stupidly long form.