Artificial grouping of developer modules into 1, 2, and 3 doesn't make much sense to me. Either put them all together, or create something a little more human-readable. Basically, what's needed is a sub-package name, since most developer modules are put into a Development package.

Comments

owen barton’s picture

owen barton commented

The idea was that these are "priorities" - I am not sure exactly how it would work (and it could be up to people to determine their own practices of course), but I was thinking that it could look something like this: priority 1 could be modules you always want enabled, priority 2 would be modules you might want to enable occasionally (as a batch), and priority 3 would be modules you still want readily available, but would enable individually as needed. I am open to other ideas too - I think having "packs" (logging, debugging, performance, testing etc) could work too, but it might be had to figure out what goes in what pack/category, and even then there may still be a some modules you always or rarely want. I guess we could make a separate pack for those?

Grayside’s picture

Grayside commented

So a sub-packaging tag does make some sense. As would a drubuntu command to toggle all modules in a given set.

There's kind of a fine line between a development package and a module a given developer will virtually always use. For example, I install ctools, cck, views, features, strongarm, etc... by default in every site. Shouldn't such ubiquitous modules be supported somehow in this module set idea? Maybe sets should be definable in .drushrc (not for download perhaps, but for set-toggling).

Grayside’s picture

Grayside commented

Things needed (imo):

1. A drubuntu concept for module sets, such that drush en priority1 --drubuntu-set might work. Drubuntu could then implement drush_drubuntu_pre_pm_enable(), check for that flag, and use it to swap out the argument. It would also be cool if pm-download were similarly extended with a drush dl --drubuntu-set so the code base could be refreshed or new modules added based on that manifest. (This might be more complicated if a clean-sweep is worthwhile here.)

2. Going from hard-wired priority levels and projects to something more user configurable. I am actually picturing something like a drush_make array structure which would allow developers to specify module versions, associate it with a module set, and so on. A default modules list should be held in a dedicated file, such as default.development_modules.drushrc.php which could be copied off to the various drushrc-friendly locations. This also answers the question I raised in #2 by allowing individual developers to decide how they want to use this.

3. Allow a hook- drush_hook_drubuntu_development_modules_alter() to change how the modules are organized. In this way if a user downloads and installs a new development module, that module can insert itself into a module set for management via #1.