Often, a project has but one module, and its module has the same name as the project. In instances when this is not the case, though, it can cause confusion (e.g. #862460: pm-enable command not working?).

Much of this confusion could be avoided if drush dl would print out a confirmation message that contained the module names. For example:

The project google_analytics contains 1 module(s): googleanalytics

This message could appear after the existing "downloaded to" message, and could be suppressed in the canonical case (that is, when the module name matches the project name).

CommentFileSizeAuthor
#1 866716-dl-modules.patch2.05 KBgreg.1.anderson

Comments

greg.1.anderson’s picture

greg.1.anderson commented
Status: Active » Needs review
StatusFileSize
new 866716-dl-modules.patch2.05 KB

Here it is. An example below: a project with one module with the same name as the project, a project with one module with a different name than the project

$ drush dl google_analytics
Project google_analytics (6.x-2.2) downloaded to
/home/ga/tmp/google_analytics.
Project google_analytics contains a module named googleanalytics.
$ drush dl notifications_extra
Project notifications_extra (6.x-2.0-beta2) downloaded to
/home/ga/tmp/notifications_extra.
Project notifications_extra contains 4 modules: notifications_custom,
notifications_feed, messaging_notify, notifications_nice.

(n.b. I removed "[success]" tags from the above log for readability.)

The log message uses $project['project_type'] to determine the type of project being downloaded, so it will say "theme" instead of "module" if appropriate.

moshe weitzman’s picture

moshe weitzman commented

Perhaps a --pipe should be added so a script can parse the output of this? Just a thought.

greg.1.anderson’s picture

greg.1.anderson commented

For scripts, I think I'd rather have a separate pm-modules command. With pm-download, there's both the download location and the module list to worry about. How would that be formatted? Maybe like this:

/path
m1,m2,m3

There's a bit of a parsing problem, esp. if there are multiple projects being downloaded.

moshe weitzman’s picture

moshe weitzman commented
Status: Needs review » Reviewed & tested by the community

Makes sense. Feel free to commit this when you are ready.

moshe weitzman’s picture

moshe weitzman commented

Hmm. Is download location really needed? Couldn't one just pass the list of modules to pm-enable and let it do its thing?

greg.1.anderson’s picture

greg.1.anderson commented

I guess that the download location isn't necessary, because you can always use dd to get that later. I'll add --pipe as you suggested above. If you want, I could also add drush dl --enable google_analytics to download + enable a module...

greg.1.anderson’s picture

greg.1.anderson commented
Status: Reviewed & tested by the community » Fixed

Committed with --pipe but without --enable. Also committed #870852: drush --pipe should print nothing rather than "Array ()" when there is no output so that drush pm-enable `drush pm-download --pipe modulename` will work right in the error case.

greg.1.anderson’s picture

greg.1.anderson commented
Status: Fixed » Patch (to be ported)

This could go in 3.x too.

anarcat’s picture

anarcat commented
Status: Patch (to be ported) » Fixed

We have discussed the policy of the drush 3.x branch at a BOF at Drupalcon CPH and it was agreed to only include critical and security fixes on the branch, to make it easier to sync in the official distributions (e.g. Debian). New features and small bug reports like this one, unless really critical or security, will therefore be refused for the 3.x branch.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.