Here is an interesting edge case. I want to add the Grammar Parser library to my profile, which is built for Drupal 6. To do so I need to include the D7 code and apply a patch for D6 compatibility (as per the library documentation). To do so I need to fetch Grammar Parser from git or the Drupal FTP. In either case I have problems with drush make verification. If I use git, the error is:

The project-level attribute 'revision' on project 'grammar_parser' is [error]
not allowed.
Could not retrieve version information for grammar_parser. [error]
The drupal.org validation check failed -- see [error]

If I use FTP the issue is:

The project-level attribute 'version' must be specified when the [error]
project download-level attribute 'revision' is specified on project
'api'.
The download-level attribute 'url' can only be used if it is pointing [error]
to git.drupal.org. The URL for project 'grammar_parser' is invalid
(http://ftp.drupal.org/files/projects/grammar_parser-7.x-1.1.tar.gz).
Could not retrieve version information for grammar_parser. [error]

Is the solution here to add Grammar Parser's d.o. URL to the packaging white list or am I going it wrong? (or is Grammar Parser doing it wrong)?

Comments

geerlingguy’s picture

geerlingguy CreditAttribution: geerlingguy commented

This is an odd case, and I'm inclined to close the issue or postpone it, and maybe suggest asking the Grammar Parser maintainer to create a separate D6 branch of the module (using the patch you suggest), so that you and any number of other people could simply include the module like any other in your install profile.

There's really no reason we should need to whitelist 'external' libraries that are actually hosted on drupal.org...

Also, I haven't really looked into patching mechanisms in install profile packaging, so you'd need to ask elsewhere for help with that syntax in your makefile.

dww’s picture

dww
we/he/they
CreditAttribution: dww commented
Category: feature » support
Status: Active » Closed (works as designed)

This isn't a library whitelist issue. The whitelist is just for the URLs for 3rd party code that doesn't live on Drupal.org.

In this case, you're just not using drush make properly. You need something like this:

projects[grammar_parser][download][type] = git
projects[grammar_parser][download][revision] = [some hash]
projects[grammar_parser][download][branch] = 7.x-1.x
projects[grammar_parser][patch][] = http://drupal.org/files/some-patch
rickvug’s picture

rickvug CreditAttribution: rickvug commented

@dww In this case there isn't a 7.x-1.x branch to use so there's still a problem. You're right to mark as "won't fix" though. The real solution is for the library to branch according to conventions so that Drush Make can work as designed.

dww’s picture

dww
we/he/they
CreditAttribution: dww commented

@rickvug: Then branch from master, whatever. Or if there's an official 7.x-1.1 tag, you can just use that directly:

projects[grammar_parser][download][type] = git
projects[grammar_parser][download][tag] = 7.x-1.1
projects[grammar_parser][patch][] = http://drupal.org/files/some-patch

But yeah, sounds like grammar_parser is a moving target being oddly/poorly maintained, so helping the maintainer(s) to to stabilize the code is probably a good next step. ;)

rickvug’s picture

rickvug CreditAttribution: rickvug commented

That is very similar to what is in the make file now:

projects[grammar_parser][type] = "module"
projects[grammar_parser][download][type] = "git"
projects[grammar_parser][download][url] = "http://git.drupal.org/project/grammar_parser.git"
projects[grammar_parser][revision] = "b88801a947203b46cb742d80b0216de407ea003d"
projects[grammar_parser][subdir] = contrib
projects[grammar_parser][patch][] = "http://drupal.org/files/994518-7.2-to-d6.patch"

This is not working with the packaging system. The only difference that I see is type=module. Could that be what is causing the problem (ie. the check against d.o's update server)?

Thanks for your help in addressing this issue.

dww’s picture

dww
we/he/they
CreditAttribution: dww commented

'revision' is supposed to be in the 'download' subarray, not in the top-level like that. I just added https://drupal.org/node/1432190#project-level to hopefully help you (and others) understand this error message and how to fix it.

rickvug’s picture

rickvug CreditAttribution: rickvug commented
Status: Closed (works as designed) » Active

@dww I fixed that issue and managed to pass verification. However the build itself is failing. Here's the error from the release node at http://drupal.org/node/1491732:

Packaging error messages

ERROR: /usr/bin/php /var/www/drupal.org/tools/drush5/drush.php --include=/var/www/drupal.org/tools/drupalorg_drush make --drupal-org=contrib --drupal-org-build-root=/var/tmp/tag.12681/apisite --drupal-org-log-errors-to-file --drupal-org-log-package-metadata=metadata-contrib.json drupal-org.make . failed with status 1
 >> Project ctools contains 9 modules: ctools_ajax_sample, views_content, ctools_custom_content, bulk_export, page_manager, stylizer, ctools_access_ruleset, ctools_plugin_example, ctools.
ERROR: >> Unable to patch grammar_parser with http---drupal.org-files-994518-7.2-to-d6.patch.
ERROR: Build for apisite-6.x-1.0-alpha6-no-core failed.

The patch applied for me locally when I checked git apply so I'm not sure what's happening here. The make file in question looks simple and correct, at least to me : http://drupalcode.org/project/apisite.git/blob/0317a704e43008cfe4aea9140.... Any suggestions to get past this last hurdle?

solotandem’s picture

solotandem CreditAttribution: solotandem commented

Check the patch application code in drush make. Is it using "patch -p1" or "patch -p0" to apply the patch? The patch in question is in p1 format. Your error message indicates drush 5 which I would assume to use p1. I tested the make file in #19 of #994518: Use in a Drupal 6.x environment today and it builds successfully.

geerlingguy’s picture

geerlingguy CreditAttribution: geerlingguy commented
Status: Active » Closed (won't fix)

Marking this closed, due to lack of activity; plus, this thread seems better suited in some other place, maybe under drush make or something, as it's not really a whitelist issue, but rather the use of drush makefiles.