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.

Files: 
CommentFileSizeAuthor
#5 libraries_info_test_drupal_org-gitdiff.patch680 byteschemical
PASSED: [[SimpleTest]]: [MySQL] 135 pass(es).
[ View ]
libraries_info_test_drupal_org.patch609 byteschemical
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch libraries_info_test_drupal_org_0.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Comments

Version:7.x-2.0-alpha2» 7.x-2.x-dev
Priority:Major» Minor
Status:Active» Needs review

Status:Needs review» Needs work

The last submitted patch, libraries_info_test_drupal_org.patch, failed testing.

I 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! :)

As 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

StatusFileSize
new680 bytes
PASSED: [[SimpleTest]]: [MySQL] 135 pass(es).
[ View ]

My 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.

Status:Needs work» Needs review

Re @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.

Status:Needs review» Fixed

Decided 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...

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.