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.First of all, no offense to anyone here with this bug report, I find the work done with drush make on d.o amazing! and best of all, it works!
Well, that's when you've managed to understand some of the obscure messages you find on the way. I created the schemaorg_kickstarter install profile to give this new system a try.
I generated my distro.make with drush make (drush 5). I'm pasting its content here since the raw gitweb link does not work:
; This file was auto-generated by drush_make
core = 7.x
api = 2
projects[drupal][version] = "7.12"
; Modules
projects[ctools][version] = "1.0-rc1"
projects[date][version] = "2.0-rc2"
projects[features][version] = "1.0-beta6"
projects[recipe][version] = "1.2"
projects[strongarm][version] = "2.0-beta5"
projects[views][version] = "3.1"
projects[schemaorg][version] = "1.x-dev"
I pasted this in http://drupal.org/node/1439192/convert-make-file hoping to convert it to a drupal.org compatible format. I pasted that code into drupal-org.make. I created a dev release and waited a little bit. When I next checked, the release was still unpublished with a red message about an invalid 'core' attribute -- both API version and release are required. The convert script gave me core = 7.x-dev so that was wrong.
Two suggestions:
- This error message was a bit confusing, calling the major core version 'API version' and the minor version 'release'. Is that a new convention? Does 'API version' refer to the api property api = 2. 'release' to me means an actual release number, like 7.10 or 7.12.
- Maybe this message could use an example too.
Moreover I don't know where I screwed up to end up with core = 7.x-dev... I ran drush make from a vanilla 7.12 tarball and I ran drush dl beforehand for all the contrib required. I don't know why the convertion script didn't say anything if this is not allowed. Actually, it says in the logs: ; [ok]: Setting the Drupal core version to 7.x-dev. which goes against the error I got above. I ended up setting the core property to 7.12 and it worked.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | 1440412-4.allow-vague-core.patch | 2.3 KB | dww |
Comments
Comment #1
dwwThanks for the report, and you're welcome for the d.o distro packaging system. ;)
a) Yeah, convert-makefile is broken and weird. It should die. See #1474796: Kill convert-makefile code
b) That thing about core needing to be specified exactly is also a bit wonky. It's actually directly from the d.o packaging script, not even drupalorg_drush. :( That's a big part of the problem -- the drupalorg_drush tools don't know about this restriction since they're not even enforcing it. This is lame. In fact, *I* didn't even know about this restriction until I was hacking all of that code for #1455614: Packaging script doesn't allow distributions to patch core or specify a git revision. ;) That patch is already touching a lot of things, so I'm hesitant to change all this at the same time.
Therefore, when the dust settles on #1455614 I'll circle back in here and clean this up. Should be easier once that's in. It might involve a change to drupalorg_drush, but maybe we can just remove this restriction in the packaging script itself since it should no longer be needed given a bunch of other recent fixes/improvements.
Also, giving this a more descriptive and precise title so we know what we're actually talking about here.
Cheers,
-Derek
Comment #2
webchickHit this when trying to do a "simple" profile with no special tricks. The short version is "change core = 7.x to core = 7.12." However, dww and I both believe we should just fix this. Tagging/prioritizing accordingly.
Comment #3
dwwYeah, #1455614: Packaging script doesn't allow distributions to patch core or specify a git revision is done. I'll deal with this. Mostly I think it's a drupalorg packaging script fix. I don't think we need to keep enforcing this restriction anymore, but I'll have to see. Moving for now.
Comment #4
dwwThis will be easier to solve once #863938: Top-level directory in packaged install profiles should use the shortname of the install profile project is committed, since that was one of the places where requiring an exact version of core was being used. So, this patch is rolled assuming that one is committed first. Otherwise, I think this is all we need. Needs more testing, but I believe it all works as expected. If core is vague (7.x) and there's no drupal-org-core.make, we just assume you want the latest official core release by using this to build core for you:
This is lame, for all the reasons I start to explain at #1403356: Update distribution documentation about relaxed version restrictions in .make files and best practices. But, we should probably allow it instead of treating this as a fatal error. I still think the docs should encourage being precise. But, at least it won't necessarily be a total WTF gotcha if you do it the crappy way.
Comment #5
dww#863938: Top-level directory in packaged install profiles should use the shortname of the install profile project is in, so I just committed, pushed, and deployed this live. I still need to document why doing 'core = 7.x' is a bad idea, but that's for #1403356: Update distribution documentation about relaxed version restrictions in .make files and best practices not here.