Re: list packages structure incompatibility

Nice explains Greg ! Thanks a lot . Laurent Greg Beaver wrote:

Laurent Laville wrote:

i've recently upgrade my PEAR version from 1.3.6 to 1.4.4 and now to 1.4.5 without problem. i've then begun to play a bit with new features of PEAR 1.4.x and found a possible structure incompatibility problem. As PEAR_info package does not return correct result with PEAR 1.4.5 (see bug#6051 http://pear.php.net/bugs/bug.php?id=6051) i've written my own script to test on localhost [1] what was return by PEAR_Registry::listPackages() (see line 10 of my test script) and also each package datas by PEAR_Registry::packageInfo (see line 16 of my test script)

First off, I want to make clear that documentation is not finished yet on PEAR 1.4.x, so I put no blame on you for anything that is not working the way you think it should. However, you need to know that because package.xml 1.0 and 2.0 are so radically different, the way they are stored on disk is also dramatically different. package.xml 2.0 is stored as serialized XML a la XML_Serializer/Unserializer. This makes it very simple to parse xml from disk, make a change, and write it back out. What this means is that a straight call to PEAR_Registry->packageInfo(packagename) returns the raw data. Calling packageInfo with a key as in PEAR_Registry->packageInfo(packagename, 'package') will still work, but working with the raw data will not work in PEAR 1.4.x What *will* always work is to use PEAR_Registry->getPackage(). This returns a PEAR_PackageFile_v1 or PEAR_PackageFile_v2 object. These objects share a common API that can be used to access information and/or modify it. Through this abstraction (which should have been implemented a long time ago) it is possible to treat the object returned from getPackage() as a PEAR_PackageFile_v1 and you are guaranteed that it will work, as PEAR_PackageFile_v2 is basically a superset of the methods provided by v1.

I thought that the solution was easy (see line 21 of my test script) but it didn't worked for all packages. Perharps a structure incompatibility problem in new PEAR 1.4.x ? Greg ?

This is exactly correct, and using getPackage() you eliminate the problem.

i got : - 32 packages that return no xsdversion info (see lines 17-19 of my test script)

Yes, xsdversion is ONLY set if you install a package.xml version 1.0 package using PEAR 1.4.x. If you installed it using 1.3.6 or older, it will not have that field.

- 38 packages that are supposed installed by a package.xml xsd 1.0 - and only 4 packages that have dual compatibility package.xml xsd 1.0 and 2.0 here are the list on my installation: Date PEAR PEAR_PackageFileManager XML_Parser So i've decided to replace (line 21 by line 22 to fix it). It could be a solution (not the best one) for bug #6051 !

I think the best solution is to do: if (method_exists($pearRegistry, 'apiVersion') && $pearRegistry->apiVersion() == '1.1') { $info = $pearRegistry->getPackage($package); } else { $info = $pearRegistry->packageInfo($package); } if (PEAR::isError($info)) { continue; // essential error check } if (is_object($info)) { // use $info->methods() to access stuff // works for package.xml 1.0 and 2.0 and any minor // future changes - guaranteed } else { // use $info['field'] to access stuff } Greg