Module management in Drupal
The title of this page should be project management because Drupal uses projects for delivering modules.
A companion video shows the Drupal 5.x situation. Using drush, my drush_mm patch and update status to manage and install modules command line. This video shows better dependency checking than currently available in D7. As I hope is clear I want to contribute to implement this into D7.
Drupal has a few tools for managing projects. drush and update_status are capable of updating a project. This is done by downloading tarballs. There is no better management available at the moment. After a project is installed onto the filesystem module management comes into play.
This blog and others is about my vision how package/project/module management should be done in drupal 7
The actors (in short) are:
- module.inc
- Is capable of enabling/disabling and installing a module. I haven't found the uninstall!
- install.php
- Is capable of installing drupal and a chosen profile
- update.php
- Is capable of doing an update and/or upgrade
- drush_pm
- With drush_pm packages can be downloaded commandline
- update_status
- Checks for new versions is done
- drush_mm (a patch for drush in progress)
- (un)install and en/disable modules
What do we miss in this list?
- module dependency management. When enabling a module from a project like ubercart the admin user has to enable modules multiple time. Just because the dependency check is not deep enough. Same goes for disabling. (drush_mm can do this)
- uninstalling has no dependency check whatsoever. I'm not sure whether it should have but modules with a parent child relation should definitely be dependant in handling the relation before the parent disappears.!
- downloading project tarballs from core. (drush_pm can do this.)
- project providing module or how to find the project a module belongs to. Ie with ubercart one can install google_analytics but the project name is googleanalytics (without '_'). How to resolve this?
- project dependency management. Some project version need specific other project versions
In my next blog I will elaborate on these missing issues and talk about solving dependancies the better way.
Comments
Not in core = bad
So I think this is really nice, not only due to the efficiency it adds to management of modules but mostly as it allows for easier installs of modules. One thing I am troubled about, is the lack of scaling - ubercart might sound fine - but how would this work in a 35 contrib modules enabled environment. Surely you dont want to uninstall All your modules, when you uninstall token? Perhaps for the interface, we need more sensible defaults.
Post new comment