Add drush views-list command

Here is a first go at it:
drush views-list
or:
drush vl

The patch looks good. A very useful command.
Can you add an entry in the hook_drush_help() ?

OK, here's some progress,

drush help views-list

We now also list the tags of each view in the table.

There's now a new option available when you call the command:
drush vl --tags=tag1,tag2

I've also renamed the function to the default taken by drush, following best practices.

Great ! I corrected small typos, and proposed small improvements to output. What do you think ?
And hey : I don't know how to roll patches with Git... Looks like my patch is against your previous patch, uh ?

And a question : how do you debug code that prints in the command line ? You cannot use dsm or a debugger like xdebug I suppose... Do you 'drush print' stuff ?

Awesome addition!

Some documentation feedback:

1) Don't end the sentence with "by", Core also uses comma-separated.

+      'tags' => dt('A comma separated list of views tags to filter the results by.'),

becomes:

+      'tags' => dt('A comma-separated list of views tags by which to filter the results.'),

2) Consider standardizing on using the word "Display" or "Show" in place of "Prints out" and "get". (`drush pm-list` uses "show").
3) 'the system' is not used elsewhere in other drush command documentation, and is probably not necessary.

+      return dt('Prints out a list of views in the system with information about them.');

becomes:

+      return dt('Show a list of available views with information about them.');

and

+    'examples' => array(
+      'drush vl' => 'Get a list of all views in the system.',
+      'drush vl --tags=tag1,tag2' => 'Get a list of all views tagged as tag1 or tag2 in the system.',

becomes

+    'examples' => array(
+      'drush vl' => 'Show a list of all available views.',
+      'drush vl --tags=tag1,tag2' => 'Show a list of views tagged with tag1 or tag2.',

Functional review to come....

One more nitpick, a classic dilema in English: on versus in.

I think in this case, "in" sounds and reads better.

+  drush_print("A total of $total views were found on this Drupal installation:");

+  drush_print("A total of $total views were found in this Drupal installation:");

I have 112 views on a production site of mine, and this list would be hugely more helpful if it were sorted by view name alphabetically by default, just as the Views UI does.

I tried to modify the line where views_get_all_views() is called, to add a ksort, but it consistently showed zero views :-/ my php fu is weak today.

Actually, Views UI seems to sort first by status (enabled at the top, disabled at the bottom) and THEN by view name.

@DjebbZ you can use the drush function drush_print_r($mystuff);

@jrguitar21 many thanks for the reviews, they all make sense. I'll get to them soon.

OK, here is some more progress.

I've worked on what you did DjebbZ, which made sense. I've made the changes to the text strings you mentioned jrguitar21, and the table is now built like this: First we sort the enabled and disabled views separately, and then we put the enabled first and then the disabled views.

The result is a list with the enabled on top, each group sorted alphabetically.

I've also made some changes to the code structure so it makes a bit more sense and it's easier to read.

We're getting closer to a perfect command here :)
One suggestion : should we put the "Tag" column just after the name column, like Views UI ? Because a tag is an identifier too, it should be close to the real identifier. Other columns are info.

In the patch, added 2 options :
drush vl --status=enabled|disabled
drush vl --type=normal|default|overridden

Second is a bit broken, I'm tired it's a bit late... And I reworked output with a not-proper-yet-because-it's-late summary of all options used, the same kind I added before with "Views tagged [tag]". And I didn't move the "Tag" column.

This code is WIP, far from clean. Especially I wanted to use ternary conditions to test validity of user input, but I wasn't able at this time of the night... Maybe we can validate user input only if he writes proper things in options ?

Needs work and review actually.

@DjebbZ patch in #13 seems the same in #12. It does not implement --status and --type

@DjebbZ the patch 5 is exactly like my last one, I think you didn't commit your changes to git before doing the diff...

Ah sorry guys it was late... I'll post it tonight when I go back home.
A git-related question : I created a local branch for this issue. If I apply patches/make changes in this branch, how to diff against the 1st commit of the branch, so the patch includes all changes ?

git log

to find your commit ID.

After this you can use

git diff HASH 

to get a diff again the right version.

It should be the good patch. Didn't change since yesterday.
Thank you dereine for your tip :)

+  drush_print("A total of $total views were found in this Drupal installation:");
+  drush_print("  $indb views reside only in the database");
+  drush_print("  $overridden views are overridden");
+  drush_print("  $incode views are in their default state");
+  drush_print("  $disabled views are disabled\n");

It seems to be that this calls misses dt(). Not sure whether it should be applied or not

I think it should, I found calls with dt() in the devel module.

Better yet : --tags, --type and --status work, and I added a --name option. Basically you restrict the results to all views containing your string. It prints a nice summary of options used before the list itself.
I hope we're good.

bojanz told me that Drush commands should exist in their own module. I don't know if it's necessary because drush may discover by itself the /drush/views.drush.inc file, so that it doesn't impact the main module. It needs to be verified.
And all Drush commands may need more documentation, maybe appear in their own "fieldset" when you type drush in the prompt (There are "Core drush commands", "User commands", "Fields commands"). And even have their own drush-topic.

bojanz told me that Drush commands should exist in their own module
Well should is not have to. Is there a specific reason for it? It definitive works already in the drush/views.drush.inc file.

I'm a bit confused about

+      'drush vl' => dt('Show a list of all available views.'),
+      'drush vl --name=blog' => dt('Show a list of views which names contain "blog".'),
+      'drush vl --tags=tag1,tag2' => dt('Show a list of views tagged with "tag1" or "tag2".'),
+      'drush vl --status=enabled' => dt('Show a list of enabled views.'),
+      'drush vl --type=overridden' => dt('Show a list of overridden views.'),

For the other drush issue there were no call to dt() so i looked it up in sql.drush.inc and there were none.
Can someone clarify whether there should be some or not? drush/examples/sandwich.drush.inc doesn't use this there.

dt is simply a drush wrapper for Drupal's t. So if there is text, that is translatable... I don't see why not to use it.

Perhaps the use of dt is sparse because internationalization of Drush hasn't been a big priority as it's never seen by end users?

The standard is to not use dt() in commands description or examples although drush itself uses it in some commands. Also, I think localizing drush is not neccesarry. I've open an issue to discuss that in drush's queue #1159146: Clarify usage of dt() in hook_command().

As Moshe Weitzman said in the thread you created, in comment #7,

Yes, I agree that command descriptions should have dt().

So we should keep it, and even go and update drush core itself to include dt() in command descriptions.

Well, the conversation is going on in the aforementioned issue, looks like we should wait before deciding whether to use dt() or not in command descriptions. It is completely valid and recommended today, but maybe not in future versions of Drush.

Finally: no need to use dt() in command description, arguments, options, examples.... drush will pass strings through dt() in its internals, similar of what drupal does with items defined in hook_menu().

Thanks for the clarification.
Commited the changes mentioned in #30 for the already existing commandos.
Then i wanted to continue to try out this patch but sadly this patch does not apply anymore.

I rerolled my patch #22 and removed dt() calls in hook_drush_command. Is it the only place that needs changes ?
(git is wonderful, so easy to grab the last changes...)

Thanks for rerolling!

Commited to 7.x-3.x and 6.x-3.x. Drush integration get's better and better

Awesome! Thanks everyone for the work on this, sorry I haven't worked on it at the end... not much time lately, you know how it is...

on a side note, dereine, my name is Manuel... not Manual hahah (in commit messages) lol

Oh sorry, i'm so sorry. Next time i will c&p names again. How embarrassing

Happy for this contribution to Views :)

I noticed a problem with the command. Whenever I use it with an drush site alias when I'm outside a drupal directory, it tries to list views named [alias]. See :

drush @fo vl

Views named @fo

[...]

How come ?

w0a there's an interesting bug, I'll try dig into it soon... I'm wondering whether we should create a bug report for this though

Yes, please create a separate issue report.

#1220500: Drush views-list command doesn't work with site alias