I’ve published the very first version of a new module for Drupal, the System Features Integration module (Github). This module integrates “system objects” (basically, modules and, eventually, themes) with Features, allowing you to store module enablement/disablement status and module weight in a feature.

Why would you want to do this?

The simple answer is that this could be really useful for automated deployments. Consider a situation where you’ve deployed version 1.0 of a Drupal-based site, and you’ve got version 2.0 running on a development or staging server. Version 2.0 includes several new modules and some adjustments to module weights. Without Features integration, upgrading v1.0 to v2.0 would involve enabling the modules and then manually adjusting the module weights, perhaps by editing the database by hand or by writing a custom module update script in a .install file. With Features integration, just install the new feature module and revert the feature and – bingo! – your new modules are enabled and weights adjusted. You can even use it to disable v1.0 modules that are no longer needed.

There are, of course, other ways to do this, and your mileage may vary. Install profiles can enable modules and adjust weights upon installation, though they’re not really any help during an upgrade. Drush can painlessly enable and disable modules from the command-line, and is easily scriptable, though module weight adjustments are tricky. Obviously there’s still plenty of other work involved in an upgrade or deployment, but this module is another step towards totally features-driven development and deployment; it moves one more aspect of configuration out of the database and ad-hoc update scripts, and in to features.

Future plans for the module include support for enabling/disabling themes, and for more complex module enablement settings. In the meantime, I’d love to hear from people using the module, or those who have useful suggestions about how it could be improved.