I still forget how to do the database and user creation and drop goes. So why not make a note.

Creating

create database test;
create user 'test' identified by 'pwtest';
grant all on test.* to 'test'@'localhost' identified by 'pwtest';

Cleaning up

drop user test;
drop database;

Yeah ... call me stupid ;-)

In building my clieop3 module together with uc_payment_direct_debit I ran into the missing of documentation about the callback parameter $op of hook_payment.

That was a bummer. Because the drupal development process is still a lot of reverse engineering. Having read Pro Drupal Develpment eases the pain a little. Finding ones way studying other modules is ok if it's not on a daily basis. I must be doing something wrong.

The good side is that this $op gets documented now.

My conclusion would be to make module.inc the key module for module and project dependency management.

Changes to install.php, system.module, update.php are relative easy to do afaik.

What i haven't covered is schema update dependencies.

Steps to take:

1. make drush_mm more robust as a showcase
2. patch module.inc with lessons learned from drush_mm
3. provide the project provides files same like status_update
4. with this into place drush (D7) could have lean and mean drush_pm and drush_mm modules

This is a tricky part of package management. I have no ready solution apart from 'have a look at debian packagemanagement'.

For installation the dependencies attribute of a module should contain a version expression. In example dependencies: token (<= 1.4)

Apart from security risk i think it would be great to have drupal install modules needed for a profile. For a commandline solution provided by drush the advantages are great.

Combining 'project provides' and clean dependency checks multi site users would get rid of the burden to get modules in place before installing.

When uninstalling modules the code uses a simple foreach to call drupal_uninstall_module.

My guess is that this should be in TSL order. And it will be easy to implement when we have the dependency graph of the modules to uninstall.

Question remains whether dependent modules should be uninstalled together. That is without the user selecting what modules to uninstall.

It would be neat to have a listing of all projects providing their modules. This would solve the problem with ie google_analytics project providing the googleanalytics.module.

In example the new file with extension proj google_analytics.proj would contains

provides = googleanalytics

and annotate.proj

provides = annotate, annotate_ed, annotate_bl

On the modules page this would show up as is views_ui missing (provided by views)

I don't like the idea that dependencies are not handled in a unified way. By that I mean that both module.inc and update.php code is written to handle module status. There should be a central library handling their dependencies. When we handle this in a unified way installing a big project like ubercart is easy.

When installing/enabling a module it is important to know what this module is dependent of. Ie uc_cart is dependent of uc_order. See ie http://build2be.com/sites/build2be.com/files/ubercart.neato.png

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.

So you want to have a shopping cart. With drush_mm it's a snap.

drush --verbose mm enable uc_cart

Using verbose output this shows

Given module names: 'uc_cart'
The following modules will be enabled: 'tapir, uc_store, token, workflow_ng, ubrowser, uc_order, uc_product, uc_cart'
Installing modules
Enabling (and mayby installing) module: tapir
Enabling (and mayby installing) module: uc_store
Enabling (and mayby installing) module: token
Enabling (and mayby installing) module: workflow_ng
Enabling (and mayby installing) module: ubrowser