We have a number of existing make files in production, based on the the soon-to-be-legacy drush_make code, which pull in external libraries as per this example:
libraries[jcycle][download][url] = "http://malsup.com/jquery/cycle/release/jquery.cycle.zip?v2.94"
However, I just tried using the new built in Drush make and the archive isn't extracted. It appears the filetype detection in Drush 5 is somewhat more naive than Drush make was, which I believe would inspect the HTTP headers and handle these cases accordingly.
I would mark this as a feature request were existing make files not broken in the migration.
I've attached a simple example make file, which fails in Drush 5, but builds correctly with Drush 4.5 and Drush Make 2.3
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | drush-1434386-make-extration.patch | 2.18 KB | steven jones |
| #2 | drush-1434386-make-extration-test.patch | 2.01 KB | steven jones |
| drush_make_file.txt | 232 bytes | stevetweeddale |
Comments
Comment #1
dwwUgh, yeah. That's a big problem. ;) Especially since folks are trying to use this library for distributions being packaged on d.o: http://drupal.org/node/1433402 (that's basically an example release of nodestream).
Comment #2
steven jones commentedI think this patch should provide a test that works if the extraction was working correctly.
Comment #3
steven jones commentedRight, here's a possible fix for this. With this in place the rather naive extraction code is able to work on these 'sample' download URLs in the test.
This still seems really fragile to me, we've replaced the super amazing drush make download code with with the really basic stuff in drush core, so I still think this is going to bite someone later without warning as the make api version is still 2 even though it's clearly not always compatible.
Comment #4
juan_g commentedThere has been another bug with "?" in the URL:
But that one seemed related to the "get" download type. Anyway, the issue is #1432526: External URL not recorded for jQuery cycle
Comment #5
jhedstromWhen I build the test makefile locally (from #3), the devel directory is empty (and thus the tests are failing).
Comment #6
dww@Steven Jones:
- Thanks for jumping in. Quick skim of the patch and tests looks good, although it'd be nice to look closely at what drush_make itself was doing and see if we can benefit from any wisdom that might be in there.
- The intention is that make remains compatible, even as it moves into drush core. There are still bugs, and we're finding and resolving them. Changing the API version isn't going to make it any more stable or better. But yes, I agree that some functionality has been lost, and we're doing what we can to ensure drush core can "catch up" with how drush make used to work.
@juan_g:
- That bug had nothing to do with the ? in the URL.
Cheers,
-Derek
Comment #7
dwwargh, sorry for the x-post.
Comment #8
steven jones commented@jhedstrom Odd, is there any clue as to what part of the process is failing?
Comment #9
jhedstrom@Steven Jones it's hard to say--on some builds it works, on others the directory is empty. Even with --debug on, I don't see any immediate reason. My guess is that this indicates some weird behavior with drush's internal GET cache, perhaps it behaves oddly with the url querystring values.
Another indicator of weird behavior (but may be an unrelated issue due to download type = file) is that the message is output twice for each project.
Comment #10
steven jones commentedGiven that we seem to have had a 'release candidate' since this issue was raised I'm worried that Drush 5 is going to be released with this bug, so I'm bumping to critical because IMHO drush make has been utterly broken.
@jhedstrom I'll try to have a look at what's going on.
Comment #11
jhedstromI'm no longer able to duplicate the earlier test failures, and the solution in #3 looks good to me. Committed. Thanks!
Comment #12
adamdicarlo commentedRelated issue: #1447558: Make fails for library archives with no file "extension"
Comment #13.0
(not verified) commentedRe-worded to avoid people thinking I'd actually written a proper test.