One of the downsides of writing all configuration changes as update functions in .install files is that you need to watch out for static or cached variables and module dependencies.

For example, I just finished helping a teammate debug an elusive Views problem. The symptom: some views with blocks didn’t show up in the blocks table, even after a _block_rehash in the update function. Other views were there. If we ran the update function independently, all the blocks appeared in the blocks table. What was going on?

hook_views_default_views is a great way to programmatically define views. By using the Views Export function, you can interactively create the view, then export the code so that you can make the view available on your production site without manual administration.

However, if your new view requires a table ($view->requires) that doesn’t exist, then _views_get_default_views discards it. By the time you enable the module in another update function (and you’re using update functions to do things like that instead of manually enabling modules on your production site, right?), views_cache.inc has cached the (incomplete) views list and won’t recognize that the requirements are now available.

To get around the view dependencies, comment out the $views->requires line. It’s a hack, but it’s probably better than hacking all the functions that cache data in static variables.