Drush commands to deal with changing dependencies of enabled modules.

Hi,
in a code-driven development workflow, we often get into a situation where a new version of a module introduces new dependencies, that have not been there in a previous version. While "drush en" does check those dependencies, this does not help if the module is already enabled. The usual drush commands you run after git pull, namely "drush updb" and "drush cc all", are also not able to deal with dependencies (and that is not their job).

I propose to introduce two new commands:

drush pm-enable-dependencies
Download and enable dependencies of all enabled modules (with confirm dialog).

drush pm-find-obsolete [module 1] [module 2] [module 3]
Find all modules that could be safely disabled without disabling any of the modules specified as arguments.

The two commands are already implemented in my sandbox, see
http://drupal.org/sandbox/donquixote/1436342
(or might be http://drupal.org/project/drux some day, if I don't find a better name)

drush dep
(drux-enable-dependencies)
Download and enable dependencies of all enabled modules.

drush obs [module 1] [module 2] [module 3]
(drux-find-obsolete)
Find all modules that could be safely disabled without disabling any of the modules specified as arguments.

Use case: The PULL situation

You pull code (modules and features) that a fellow developer has worked on. These modules could contain new dependencies. You run "drush updb" and "drush cc all", but the dependencies are still not enabled.

Solution:
Now in addition you run "drush dep", and everything is fine.

Use case: The PUSH situation

You worked on some modules (incl features), and want to push them upstream. Your fellow developers need to know which other modules they need to enable, so you add those as dependencies. But, how can you be sure you did not forget a dependency?

Solution:
You have one or more "seed" modules, with all the dependencies. You agree in your team that these should always be enabled.
You might also have a "personal seed module", which contains the dependencies you do not want to share with the team.

Whenever you enable a new module, and you want everyone in your team to also enable it, you add it as a dependency somewhere, so it becomes a direct or indirect dependency of the seed module(s).

You can then run "drush obs seed1 seed2 seed_personal" to identify all the modules you forgot to add as dependency. You should either disable these modules, or add them as dependencies somewhere.

Btw, my sandbox implementation could also be used for a refactored version of pm-enable ..

The code in there requires xautoload as a dependency. I wonder if that is possible to have a dependency in drush core, for specific commands? Otherwise, xautoload contains example code that allows to easily emulate it.

I think this stuff would be better off in drush core, as it seems like a vital component for code-driven development.