Add "pm-" namespace to all of the pm commands

Per Moshe; see the discussion in #550522: Change white spaces in commands by another symbol. The namespace is not consistent or enforced yet; just moving in that direction.

Dang, that drush_invoke has poked me in the eye so many times I've gone blind on one side.

Here's a new patch, this time with all functions tested (instead of just the one singular one that did not use drush_invoke). The function replacements I did were:

find -exec grep -Hi 'function drush_pm_' {} \;
./commands/pm/pm.drush.inc:function drush_pm_pm_enable() {
./commands/pm/pm.drush.inc:function drush_pm_pm_disable() {
./commands/pm/pm.drush.inc:function drush_pm_pm_uninstall() {
./commands/pm/pm.drush.inc:function drush_pm_pm_info() {
./commands/pm/pm.drush.inc:function drush_pm_pm_refresh() {
./commands/pm/pm.drush.inc:function drush_pm_pm_update() {
./commands/pm/pm.drush.inc:function drush_pm_post_pm_update() {
./commands/pm/pm.drush.inc:function drush_pm_post_pm_updatecode() {
./commands/pm/pm.drush.inc:function drush_pm_pm_download() {
./commands/pm/updatecode.inc:function drush_pm_updatecode() {

Which matches up pretty well with this:

$ drush | grep 'pm-'
pm-enable (en) Enable one or more modules.
pm-disable (dis) Disable one or more modules.
pm-uninstall Uninstall one or more modules.
pm-statusmodules Show module enabled/disabled status
pm-refresh (rf) Refresh update status information
pm-updatecode (upc) Update your project code
pm-update (up) Update your project code and apply any database updates
pm-info Release information for a project
pm-download (dl) Download core Drupal and projects like CCK, Zen, etc.

(Neat trick, drush | grep.)

You know, I remembered reading that issue (explicit callback fns skip drush invoke) some time back, and thought that maybe I should go back and fix it just as penance for forgetting drush_invoke so often. ;)

I did consider what you suggested above in #5, but decided against it because of the large number of variants. For example, drush_pm_pm_enable also has drush_core_pm_enable and drush_sql_pm_enable, most of which will never exist, and only one of which will be simplified. I also know that there are some existing drush_sql_sql_xxx functions that I'll break when I do that... but I'll put on my goggles and wade in.

Thinking of command names... we have:

* `status` = birds-eye view of the current Drupal
* `pm-statusmodules` = list of modules name, description and status (enabled/disabled)
* and I have `theme-status` in #530780: drush commands to administer themes, that provides a list of theme name, title, description and status similar to statusmodules

I suggest to rename `pm-statusmodules` to `pm-status-modules` so we can implement `pm-status-themes` and why not `pm-status-profiles` and perhaps `pm-status-libraries`. Additionally `status-search` could be an alias for `search-status`.

#7 looks good to me.

a followup task which i started but never got anywhere near done; add a debug log entry showing all possible drush_invoke() variations. it would be a long list, but helpful IMO. probably just space delimit each function. if we have to loop over the list twice, thats fine. is OK to log rollback separately.

in theme-list there're two extra columns for Default and Administration theme (yes/no). We could suppress them and add two lines to status (core).

So unifying `statusmodules` and `theme-list` in pm-status is possible but I prefer to rename `statusmodules` to `pm-list` as statusmodule can suggest it shows an update status.

I think also of `info` command. It provides releases info. I use `theme-info` that provides detailed info about a theme (engine, stylesheets, etc). There's no equivalent command for modules (to show dependencies, ...). We could use `pm-releases` replacing current `info`and introduce new `pm-info`.

I'm trying to not hijack issues so my proposal here is cleanly the following renaming:
* statusmodules -> pm-list
* info -> pm-releases

and based on that, other issues will evolve in one or another way.

Okay, I'll do the pm-list and pm-releases renaming when I fix up the documentation for drush_invoke later today or Sunday.

Committed with documentation. I also slipped in some (temporary) backwards compatibility for contrib commands that might be using the "drush_foo_foo_xxx" naming convention (functions with the old name produce an annoying nag error in the log).

Sorry about that.

Is the backwards-compatibility code not working in Aegir?

This was working with the pm module when I tested it. The call to drush_log is flagged as an "error" even though it should really be a "warning" or even a "notice". Does Aegir work okay if this log is changed to a notice, or is the backwards-compatible feature in fact broken?

I'm sad about this.
From a casual user perspective, the commandline has now taken a few steps back into the arcane.

I understand why the code is marginally better by using a namespace.
But I think it's significantly worse by not using plain English and intuitive names any more.

This will badly hinder any adoption curve, IMO.

Comparing with tools like CVS, git and svn, this prefix is ugly. It's not the users job to know or care which code file is providing the function, just that the named function exists. Making the user do extra work every single time they type so that the magic internal function-name-scanner finds the pattern easier to guess is not helpful.
Even though I've already created my own namespace conflict just within my own experiments, I think that core drush commands are allowed to be exempt from any rule like that. They can own the name, they win.

:-(
The provided aliases are also arcane.
The "extra work" is not the typing, it's recalling and translating what you want to do into a made-up application-specific cipher each time.

If I update using cvs, I type:
cvs update

If I want to update using drush, it's now
drush {something drush-specific I'm supposed to have remembered}

I know that if you develop actively on the internals, it's obvious that "update is part of package manger which is in a file called pm so that's what it's called, and the alias is not 'ud' ".
But IMO that's a really hard thing for users who may use this a few times a month to remember.

I guess we can deal with it, it only took me 6 years to remember the more common options for 'tar' and 'find'. And those ones were not being deliberately obsfuscated with 'namespaces'
But making the commandline harder to use seems retrograde.
Also impressive, I hadn't considered it possible until now :-B

@dman: It's not so bad as all that! All of the old pm-xxx commands have deprecated aliases in pm.drush.inc. You can keep using the alias if you want. If there is general agreement that a given command name should continue to exist in its original form, all that needs to be done is to move the deprecated alias to the aliases list, and it will be back in the command help again.

I agree with Moshe here; just make a new issue if you'd like to see some of the old commands come back. Some of them definitely should, but I for one like "pm-list" better than "statusmodules", so I'd say that the namespace has helped in a couple of instances.

Okay, posting all of those examples was definitely un-lazy. But what I think that Moshe meant by lazy was that rather than complain about the way it is, you should make a patch that improves the situation and attach it to a new incident with an appropriate explanation / justification.

Some systems allow you to enter just the first few characters of a command to select it. We could take this concept and extend it to search after the namespace portion of a command. Exact matches would be checked first, so aliases always win without disambiguation, but if there is no exact match, the user could be prompted for which command was intended if there were multiple partial matches.

In this way, you could run all of the pm commands via their simple names; 'pm-enable' could just be 'enable'. If someone defined a new command 'mylittlepony-enable', then you would have to use 'pm-enable' to disambiguate (or select the correct command via drush_choice).

If there is interest in this technique, I'll write the patch.