The package system on drupal.org adds some additional information to the info files contained in the modules when dowloading the from the site which looks like:
; Information added by drupal.org packaging script on 2012-05-22
version = "7.x-2.0-alpha2+2-dev"
core = "7.x"
project = "libraries"
datestamp = "1337646472"
This additional information breaks the libraries_info() test. Unsetting the four entries by applying the attached patch the test will also be successful when the module is downloaded from drupal.org.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | libraries_info_test_drupal_org-gitdiff.patch | 680 bytes | chemical |
| libraries_info_test_drupal_org.patch | 609 bytes | chemical |
Comments
Comment #1
sunComment #3
tstoecklerI opened #1606606: Drupal.org release packager corrupts info files that are not modules, themes, or install profiles over in drupalorg.module for the packaging problem. I'll add a short comment to explain the problem and a @see to that issue pre-commit.
...unless you feel like re-rolling for that which would be super-awesome! :)
Comment #4
sunAs the testbot proves, I don't think that this patch here will fly at all, because it removes the 'version' property.
Perhaps we should split this specific test out into a separate test case and use checkRequirements() to verify that we're dealing with a git clone/checkout and the .info file has not been tampered with.
But then again, perhaps that's not worth the effort... who's running tests on non-git-clones in the first place? :P
Comment #5
chemical commentedMy previous patch was generated with 'diff' and not 'git diff' so the path was missing a slash. I have made a new patch which can be applied with 'git apply'.
The four entries are not present in the variable $library in the test of libraries_info() when running a git-cloned version of the module. Unsetting the four entries when not present has no effect but will make the test work when fetched from drupal.org as a package. Maybe libraries_info() should unset the entries to counter the packaging problem.
@sun: If tests not necessarily are successful when a module is fetched as package from drupal.org, how do I know that the module is working as expected when fetched as a package? When you do automated testing every time you change a file you test again — actually all modules on drupal.org should be tested again after the transformation by Drupal's packaging system because the code is being modified.
Comment #6
tstoecklerRe @sun/#4: The info file itself doesn't have a version property, so unsetting shouldn't be a problem.
See http://drupalcode.org/project/libraries.git/blob/refs/heads/7.x-2.x:/tes...
Maybe we should just call this fixed and wait for the drupalorg issue to be resolved.
Setting to needs review to see if the tests pass.
Comment #7
tstoecklerDecided to commit this, to get it out of the way. Can't hurt IMO.
I added a little comment. The diff is here: http://drupalcode.org/project/libraries.git/commitdiff/c979df9
http://drupal.org/commitlog/commit/10030/c979df96b8a2a7d6fceb750f51b4c8e...