Merge update_api and install_profile_api

Hi Moshe!

Thanks, I'm familiar with install_profile_api, but I don't see how these are duplicates. Every update_api function returns an array in the format expected by hook_update_N() calls. Do you foresee that being something that install_profile_api would do as well? I have no problem deprecating this module if that's the case! :D

Thanks!

Setting this to won't fix.. :/

I see you've opened a couple of issues on install_profile_api but not one related to this issue.

Maybe try opening an issue, helping out in the issue queue and/or offering to co-maintain install_profile_api?

@nedjo, how's this? ;)

So, are there install profile API maintainers interested in having update functions like these in install_profile_api?

I think the projects should merge. Both provide some good functions. I think install_profile_api provides a better mechanism for others to extend and add support for new modules. I thin update_api has some good functions - like the features stuff. I don't see the need for two projects, they both do the same thing, which is to provide helper functions to install profiles/hook_update_N implementations.

> I think install_profile_api provides a better mechanism for others to extend and add support for new modules.

Yes, update_api is very basic in its implementation, as I've just been adding functions to the main include as I've needed them, so it would definitely benefit from merging with install_profile_api to split the functions out into different files. Some of the functions are just messy too, as they were copied and pasted directly from permissions_api. They worked, but I didn't take the time to really clean up those functions.

I agree, merging the two is the best approach. Here's a few thoughts, just opinions:

• update_api functions should be renamed to install_* functions to maintain the integrity of install_profile_api. Since update_api appears to have so few users, I prefer this approach to maintaining backwards compatibility needlessly.
• Functions I would like to keep:
  • Everything in features.inc, install_profile_api is sorely needing features integration IMO
  • content.inc: update_api_content_field_delete(), update_api_content_field_alter(), update_api_content_import() (Merge into IPAPI content_copy.inc, possibly refactor install_content_copy_import_from_file() to rely on it)
  • update_api_variable_rename(), it should be refactored to include modifying the $conf and possibly clearing the variables cache so subsequent variable_get() calls will function correctly.
  • update_api_modules_disable() and update_api_modules_uninstall(), I keep getting this nagging feeling that there is an Drupal API way to do this?
  • update_api_roles_rename()
  • update_api_get_permissions_for_role(), why oh why doesn't drupal core have this function ..
• Functions I would like to drop:
  • update_api_node_type(), this function scares me .. what about orphaned rows in {node} or a plethora of other contrib tables?
  • update_api_variables_sql_set(), I'm intrigued by this. Honestly, I've done this sort of thing more often than I would like to admit, but it does feel a bit hackish to include in an API module?
  • update_api_variables_set(), this doesn't save LOC and decreases code readability (IMO).
  • update_api_variables_del(), ditto
  • update_api_permissions_grant(), duplicate of install_add_permissions(install_get_rid('ROLE NAME'), $perms)
  • update_api_permissions_revoke(), ditto see install_remove_permissions()
  • update_api_get_role(), duplicate

I am closing this issue, as Drupal 6 is now not supported.