drush_get_context has some unexpected and surprising behavior: if the requested context value has not been initialized, then drush_get_context will SET the context to the provided default value. If no default value is set, then the context becomes array().

Imagine that you have some existing Drush code that looks like this:

[A] if ($condition) { drush_set_context('FOO', $value); }

[B] $var = drush_get_context('FOO', $default);

As it stands, $var will equal $default if 'FOO' is not set. If, however, you add some new code that runs before [B] that calls drush_get_context('FOO'), then the 'FOO' context will always be initialized, and future attempts to check the context will be unable to determine whether or not 'FOO' has been initialized by [A]. Thus, drush_get_context('FOO') is the poison pill that kills future code that tries to use the Drush context default-value feature.

Quick attempts to change the behavior of drush_get_context break Drush core. We could fix up everything that is broken, but that would probably also introduce some suffering on Drush contrib modules. Perhaps the best time to change the behavior of 'get' would be when the context system is rewritten using classes.

In the short term, avoiding the drush_get_context default-value feature is best. This patch removes some code in pm-download that is susceptible to the poison pill.

CommentFileSizeAuthor
drupal-major-version.patch1.44 KBgreg.1.anderson
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

greg.1.anderson’s picture

jonhattan’s picture

I figure you didn't remove the context assignment in _drush_bootstrap_drupal_root() for contrib care. I guess it can be removed in master and preserved in 5.x.

moshe weitzman’s picture

Status: Needs review » Reviewed & tested by the community

Patch looks good. Sure, lets fix this in master but leave drush5 alone.

greg.1.anderson’s picture

Made three commits:

27a10cf: Committed #0 on master.
8264968: Removed context assignments on master per #2
5e9d995: Added a comment to 7.x-5.x branch.

The pm changes in 27a10cf could be backported to 5.x if desired, but I did not do that. Unlikely that bootstrap will change in 5.x, and this won't happen once bootstrap is complete. I guess commands that start off BOOTSTRAP_DRUSH and then call bootstrap_max() might have trouble.

greg.1.anderson’s picture

Status: Reviewed & tested by the community » Fixed

Status: Fixed » Closed (fixed)

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