drush statusmodule --package: Package column and grouping for the statusmodules list

Attached is an updated patch.

The previous one had a bug (usort instead of uasort) and was including another fix of another issue.

Yeah, I agree about the width stealing problem, that's why I added it as an optional commandline argument, so if you have a wider console screen, you could use it.

Yeah, this issue aim not only to display the project type but to group (sort) by package name first and then project name. And yes it's probably referenced to just modules. If description is gone, this can be a default display and not an optional argument. I'll keep an eye on that issue and see if this patch needs updating.

So, what do you say, package to be there by default, or by a command line? or the command line to filter, is that something already implemented somewhere else (a --filter command).

Want me to provide a patch for this or somebody else working at it?

Ok, here's the patch following the latest changes on drush, a few notes on this patch:

- Sorting of the projects happens by default, I guess this can be removed, although it gives a more coherent output. (Sort criteria: project type, project package, project name).
- I haven't truncated anything, it doesn't look that bad, but let me know if that's needed when reviewing, and also, if there's a drush way of doing it.
- --package supports multiple values as #725686: enhancements for --type, -status and --package, multiple values and case insensitive filters. The package column is displayed in two situations, if none or more than one filter was given. Now that I think of it, it may not be that useful, let me know otherwise. If you like this approach, however, the --status filter patch of the previous issue would probably need some similar logic as this one. Shall I remove the package column altogether when one or more packages were used as filters?

One question before I get to look at the feedback.

1. The "Other" should be only something handled on the display of the status or you'd prefer this to be part of the actual $project object when loading it?

2. Not sure as I never checked this out for D7, but isn't there profiles listed as well? (I think I heard it somewhere). If so, do they have packages? Or would those be displayed as Profile?

3. Probably not needed any more. right.

I don't need to really put it in the $project object, that's really changing some deeper API, if preferred, I look it up. But I can work out the sorting and the display of Other withing the pm list and the sorting function.

Well, I tried to cover most things requested on this issue, including the inconsistency reported by jonhattan on #18.

One some small different things I did:

- For themes, if a base theme is declared, that's used for the package column, if not, Base is displayed (rather than Other).

I also update the help a little bit, so you may want to review that.

Sorry, some small further changes I missed in the previous patch:

- The use of 'Base' was not used the same way on the sorting and the display, now it is.
- Use of dt() around 'Base' and 'Other'

Are you using the latest patch (3x). What version of php? I don't get that warning and I am certainly not modifying the array in the function. I really don't get that warning.

EDIT: Even more, I don't find any useful mention of that warning on google at all, which is rather strange.

Really strange. D7 I haven't really tested, I will though. But definitely on D6 and without any errors or warnings. I guess that one might be one way I am using to define a variable name which may not be working. Strange it worked on my side though, php 5.2.12 here. Will try to rework that bit at least for D6 and check that error on D7.

OK, I followed most johanttan suggestions, with the following comments/changes:

- I created the drush_pm_get_projects() functions as he proposed. IMHO, I also like this approach rather than modifying drush_get_projects() not that much because of the overhead, but drush_get_projects() seems more as a wrapper function to low-level environment-specific functions, and I guess that specific logic for pm-commands should be within the pm plugin/module, whatever this is called within drush :). I do have a question about this, I am using this function on pm-list and pm-info only, but drush_get_projects() is called in a few other places within the pm module, what should be do there?

- I slightly changed the way the $type filter worked before, by resembling exactly the way status filter works. Before it was calling drush_get_' . $type . 's', but with the new function explained above, I'd rather don't do this, and just filter types in the foreach {} just as we do with any other filter, with only single call to drush_pm_get_projects().

- Sort function is a lot simpler now, so I hope moshe will find no errors.

- Tested on D5, D6 and D7

* It would be great if the fix for drush_pm_info() also sets the base theme as package name for themes.

I haven't done anything around this yet. Again, IMHO, base theme is base theme. Although we are using the package column to build a coherent display of themes and modules, package is not a familiar term within themes, so I rather stick with Base theme (and that's being displayed on the info already). Maybe just for semantic sake, we could call the Package column on the display Package/Base theme, but I don't think that's even necessary.

I take a few things back from my previous post, I have reconsidered a few things by looking a bit further into D7.

There is a package entry now on the info files for themes on D7 (Core themes are packaged as Core). So from that point of view, I think using the base theme for the package column on the sm command is not appropriate. I rather stick to package for all version of drupal, and use 'Other' for those themes with no packages.

With this, the idea of filtering by all themes based on one base theme (zen for example) is not there any more, but if that's a feature you'd like to have, I rather code it as another filter (--basetheme) rather than using a --package filter for mixed purposes, even more when on D7 you have both things on themes (package and base theme).

So here's this new more standard approach, adding Other to both module and themes as package if there's none. I now did add the Package info to the pm-info of themes and also fixed an error in the display of the Base theme there.

+++ commands/pm/pm.drush.inc	2 Mar 2010 14:57:09 -0000
@@ -586,7 +653,9 @@ function _drush_pm_info_module($info) {
+  print_r($info);

Ups, my bad, removed on this patch.

Powered by Dreditor.

* $data['Package'] can be refactored up to drush_info_project(), enclosed by if (($info->type == 'module')||($major_version >= 7)) {}

done, although not needed to enclosed it by that if condition, because package is there (added by drupal_pm_get_projects() for everything if there's none defined).

While I am here, and probably for another issue, but if you all want I don't mind adding it to this patch, I think having the output of the pm-info command alphabetically sorted is a better looking approach, although the title should probably go first.

we can do return drupal_set_error all on 2 line. i know thats existing code, but needs fixing.

you mean removing drush_log(dt('Aborting')) and doing return set error, you surely meant 1 line, didn't you?

this is debug code? please remove.

Yes, that was there already, I just moved it, but I'll remove it.

Done with all your requests and fixed one slipped through bug in which the type column was being output regardless of the presence of --type .

I am glad to help :)

Follow up patch on #725686: enhancements for --type, -status and --package, multiple values and case insensitive filters