When Drush Make fails to apply patches...

Submitted by Frederic Marand on
Drupal tips and tricks

The issue

These last few days, I had noticed a problem with Drush Make and patches: some patches, be they rolled by our team or from elsewhere, would apply without a glitch, but some others, which worked normally according to the test bot on Drupal.org, would fail to apply without any obvious reason.

I had mostly put it out of my list of pressing issues when I really had to use an old version of OpenLayers, 7.x-2.0-alpha2 to be specific, AND apply a patch fixing one of the bugs in that module: behaviors plugin not being located correctly (http://drupal.org/node/1898662 if you want details). So I rolled the patch, tested it locally, the qa.d.o bot applied it and did not report more errors than expected for that old version.... and my Drush Make install refused to apply it.

Here was the relevant excerpt:

projects[domain] = 3.7
projects[domain][patch][] = "http://drupal.org/files/domain-foreach_argument-1879502-1.patch"
; ...snip...
projects[openlayers] = 2.0-alpha2
projects[openlayers][patch][] = "http://drupal.org/files/0001-Fix-the-path-file-declaration-for-behaviors.patch"
The Domain patch applied normally, but the OpenLayers patch would't apply. What could be wrong ?

The diagnostic

After tracing my way into DrushMakeProject::applyPatches(), I got a more explicit message: neither git patch nor trusted old patch could locate the patched file, includes/openlayers.behaviors.inc. Why ?

Comparing a standalone checkout of OpenLayers 7.x-2.0-alpha2 and the one in /tmp/make_tmp_(some id)__build__/sites/all/modules/contrib/openlayers, the problem became more obvious: that file was missing, as well as a good number of others. What ? Download failure ?

Not in the least: checking openlayers.info, I noticed the version downloaded by OpenLayers was no longer the chosen 7.x-2.0-alpha2 specified in the Makefile and which it previously downloaded normally, but the currently latest 7.x-2.0-beta3. Ahah...

The fix

After digging a bit more into Drush, it appeared that whenever you specify an extra info bit about a project download, lines in the short format like projects[openlayers] = 2.0-alpha2 are ignored, so Drush downloads the latest published version. The fix became obvious: use the "extended syntax", like this, for the same excerpt:

projects[domain][type] = module
projects[domain][version] = 3.7
projects[domain][patch][] = "http://drupal.org/files/domain-foreach_argument-1879502-1.patch"
; ... snip ...
projects[openlayers][type] = module
projects[openlayers][version] = 2.0-alpha2
projects[openlayers][patch][] = "http://drupal.org/files/0001-Fix-the-path-file-declaration-for-behaviors.patch"

This also explained why the other patches applied normally: each of them had been rolled against the latest module version, so the specified version was ignored, but the version actually being downloaded ended up being the same, and the patch applied normally.

Whatever it is, I think that the situation that you ran into is kind of subtle, and not necessarily easy to track down. Since make files are stored in Drupal .info file format, the argument could be made that it is correct behavior for the project's "array" elements to overwrite the "string" (version) item. I posted a patch that took the first step towards merging these items together; we'll have to see what the other maintainers think of it. In any event, this is definitely a valuable writeup, and should at a minimum be a documentation task in the queue. Thanks for your work on this.

I think you've saved me, any many others, a lot of debugging time by posting this tip.

I was having trouble with this too.

Thanks!

Maybe, whilst annoying, it would be better to always use the long form in drush make forms, to ensure that there is no ambiguity?

What I tend to do, actually, is:

  • use the short form for completely default cases
  • use the complete form whenever something needs to be specified

That's not needed, but my subjective opinion is that it is simpler to parse visually than a sea of complete (long !) stances or, even worse, a mix of stances in various degrees of completion, each of which needs to be verified individually.

I found another case where the patch doesn't get applied.
When you are patching the info file and you are downloading the stable version drupal.org adds lines at the end that may mess with your patch.
FYI