Unai,
(d) really is the tricky part.  Some modules will play nice, others won't. Some of the easiest modules to configure in your code will be ones that use system_settings_form() to return their administrative options and configuration forms.  system_settings_form() just stores things as variables.  This means that, for a low maintenance module that does all of its settings configuration on its admin screen, the API to configure that module from other code consists of variable_get(), variable_set(), & variable_del().

I would not recommend doing this in the contrib module's .install file, ie: directly in that module's update_N hooks.  If you take mighty_contrib_module.install and add the function mighty_contrib_module_update_1() (or, more correctly, ...update_6101() ), things will work fine only until the next release of that module is available and the author has added his own first update hook.  Besides the version control conflicts in the files themselves, there will be schema version fixing needing to be done in the system table.

I would recommend creating your own local module that exists mostly to just contain the update_N hooks to configure other contrib modules (say, housekeeping.module).  Kind of like the junk drawer in you kitchen... everything useful (and not) that's together in one place just to keep it out of the way... Assuming that mighty_contrib_module had an admin setting to set the max number of words allowed in something, we could find the name of the FAPI element, and then inside of housekeeping.install write:

<code>
function housekeeping_update_1() {
  variable_set('mighty_contrib_module_max_words', 100);
  $ret[] = array(
    'success' => true,
    'query' => 'this is just a message masquerading as called sql statement for reporting purposes.',
  );
  return $ret;
}
</code>

You'll find all sorts of things to shove into the housekeeping module ;) Including some core config stuff too.

Looking at the classifications you've set out below, I'd say that (b) is really a subset of (d).  When it comes to contrib modules, there are going to be two main categories: those that play nice and those that don't.  views happens to fall into the 'plays nice' category.  Others won't.  It's an important distinction you'll need to make when you're deciding which contrib modules to use from your solution's onset, an important criteria that cannot be overlooked.

Seth

Unai Rodriguez wrote: 
Dear All,

Thank you so much for the contributions. 

I have classified different parts that currently compose our Drupal system
along with a suggested method of "putting everything in code and update
functions":

a) THEMES.- We just copy the code over, there is no settings to be applied
really
b) VIEWS.- We will be using what is suggested here:
http://treehouseagency.com/blog/steven-merrill/2008/11/05/speed-and-version-your-views
(This is similar to what Seth sent but applied to Drupal 6 -- THANKS SETH!)
c) MODULES DEVELOPED BY US FROM SCRATCH.- We will make sure that all the
settings that need to be put into the database are being updated on the
hook_update function. Ideally these settings could come from a
configuration file in php. We will use DRUSH to invoke our update.php upon
deployment, as suggested by Kathleen.
d) 3rd PARTY MODULES (aka contributed modules by the Drupal Community).- I
am not sure how to proceed with this one; for now I am trying to check if
the modules that we use implement the hook_update function and modify if
possible so the settings get loaded from configuration files, similar to
(c).

My questions are:

1) How would you handle (d)? What I have now in mind seems a bit tricky...

2) What do you think of the classification? Am I missing something? Does it
make sense?

Thank you so much.

With Best Wishes,
unai
--
[ Drupal support list | http://lists.drupal.org/ ]