Given that...

  1. foo and bar are modules that are dependent on the baz module
  2. foo and bar were previously installed and later disabled
  3. foo and bar were not uninstalled after they were disabled
  4. baz has been disabled.

Then..

When drush pm-uninstall baz is executed, Drush improperly returns success, but baz remains installed.

This behavior is particularly confusing because drush pm-disable baz would disable foo and bar and so there is an expectation by the user that pm-uninstall will behave similarly.

I saw some allusion in #1218024: Latest Drush cannot 'pm-uninstall toolbar' to the effect that more robust dependency-checking was a relatively recent change in the operation of pm-uninstall, so perhaps this is related to some of those changes. My apologies if this is already being addressed in that related work!

Cheers,
~tw

Comments

jonhattan’s picture

Status: Active » Closed (works as designed)

Let's call them ctools, views, panels.

$ drush pm-uninstall ctools
To uninstall ctools, the following modules must be uninstalled first: views, context, context_ui, panels,         [error]
file_entity, media, stylizer
There were no modules that could be uninstalled.                                                                  [ok]

Done with latest drush.

Next time please post a debug output, or at least real module names.

jonhattan’s picture

For completion, that was fixed in #1119686: pm-uninstall doesn't respect module dependencies (at least for D7) and backported to 4.x. Will be available in 4.5

t-dub’s picture

Awesome, thanks for looping back around on this to note where the fix happened. Sorry about the placeholders in the bug report; I was hoping to emphasize that it wasn't tied to particular modules, but I see how too many abstracts can make things *more* confusing. Dunno why I didn't think to post debug output; I definitely will next time.

Cheers,
~tw