Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.drush generate-makefile gives me output like this:
projects[features][type] = "module"
projects[features][download][type] = "git"
projects[features][download][url] = "git://git.drupal.org/project/features.git"
projects[features][download][branch] = "(no branch)"
projects[features][download][revision] = "dc3297e5f4141f40f46635c1bbf05913d0ae662d"
..and raises warnings (Could not locate feeds version X, downloading latest stable version) but is just fine with lines like this:
projects[drupal][version] = "7.x"
...
projects[feeds][version] = "2.0-alpha4+37-dev"
However, drush verify-makefile dies on those version warnings, and also on this:
The project download-level attribute 'url' on project 'features' is not allowed. [error]
The project-level attribute 'version' must be specified when the project download-level attribute 'revision' is specified on project [error]
'features'.
I'm not sure whose fault this is—Drush or Drupal.org Drush—but in the end it means that distro authors have to do manual futzing that they don't have to do with normal Drush Make on drush generate-makefile output. This is a major DX headache.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | 1432380-5.drush-make-generate-dev.patch | 1.85 KB | dww |
| #3 | 1432380-3.drush-make-generate-dev.patch | 1.85 KB | dww |
Comments
Comment #1
webchickTagging.
Comment #2
dwwA) This is never going to work:
projects[feeds][version] = "2.0-alpha4+37-dev"Those fancy version strings are just for core's version dependency stuff to work (and for the humans to figure out what's going on). All the underlying plumbing (on d.o, in drush pm, drush make, etc) still uses the more generic '2.x-dev' style version strings.
B) The 'url' validation thing is duplicate with #1432290: Ignore 'url' parameter when it's from git.drupal.org. Can we just talk about that in one issue please? ;)
C) The "Could not locate feeds version X, downloading latest stable version" stuff should now be resolved thanks to #1405736: Regression: make no longer smart enough to get latest release from non-recommended branch (I think).
Based on the OP, I'd say (A) is the only bug here, and it's a bug in generate-makefile, which lives in drush core, not drupalorg_drush.
Comment #3
dwwTotally untested, but something like this seems like what we need. Inside generate-makefile, if we see we're dealing with a fancy ...+N-dev version string, we special-case it and fall back to the '1.x-dev' drush make is expecting.
Comment #4
jhedstromRunning this with a random 7.x site, with and without the patch, I still see things like
However, this might be a different issue, since that's actually coded into the .info file that make generated in the first place:
Comment #5
dwwYeah, I think that's a separate problem. The regexp here is only trying to handle stuff like "7.x-1.0+17-dev". So, for example, on a new clean site with just D7 core and
drush dl field_collection-7.x-1.x-dev, I'm getting the following:Before patch:
After patch:
Although, finally testing this, I realized that my regexp was too strict, and it only worked for
7.x-1.2+17-devbut not7.x-1.0-beta3+1-dev. Attached patch is better.Do we need a functional test for this? Try to modify the existing generate test to include one of these funky -dev version strings?
That said, the more I investigate, the more problematic I think generate-makefile is. It does all sorts of things wrong from my perspective. So, although we should probably fix this, I suspect there's a lot more work to do fixing it up (and therefore, we shouldn't put too much emphasis on using it in the documentation about doing distribution packaging on d.o).
Comment #6
colanAlso, what's with this:
If I run generate-makefile on a 7.12 site, which I just did, shouldn't that be "7.12", not "7.x"? Is this another bug, or is it related?
EDIT: I've spun off a separate issue for this: #1528594: Drush generate-makefile doesn't specify stable core version
Comment #7
colan@dww: I'm not sure that your patch is such a good idea, because we'll have no idea which dev version we're talking about. At least the default human-readable-only dev versions (like "1.0-beta3+1-dev") can be fixed manually afterwards by finding an appropriate commit ID that matches the human-readable description, and then converting the entry to a git one (pulling that ID). If there's only "1.x-dev", there's no way to match this with anything, as it could be any dev version.
So perhaps we could have Drush convert these human-readable version strings into Git entries that pull down the project with the associated commit ID?
Comment #8
greg.1.anderson CreditAttribution: greg.1.anderson commentedMy opinion is that #5 should be the default, and there should be a separate option for #7. Perhaps we should commit this, and open another follow-on issue for an option to convert dev versions to specific git commits, when available?
Comment #9
greg.1.anderson CreditAttribution: greg.1.anderson commentedAssigning to drush-make maintainer.
Comment #10
greg.1.anderson CreditAttribution: greg.1.anderson commentedThis issue was marked
closed (won't fix)because Drush has moved to Github.If desired, you may copy this bug to our Github project and then post a link here to the new issue. Please also change the status of this issue to
closed (duplicate).Please ask support questions on Drupal Answers.