preview of PEAR_PackageFile2Manager

Hi all, I have hinted at this in the past, but now that I've started to work out design ideas, I thought you might like a preview of what will be happening with PEAR_PackageFile2Manager. Note that this is not the 2nd incarnation of PEAR_PackageFileManager, but a package.xml version 2.0 manager and as such is not bound by the BC-breaking release rules. PEAR_PackageFile2Manager cannot work with package.xml 1.0. OK, so here are some highlights. First of all, I designed PEAR 1.4.0 so that it would be much simpler to design a package.xml management package. Some inherent benefits that PEAR_PackageFile2Manager will experience that was not possible with PEAR_PackageFileManager: 1) output can be a string, package.xml or a fully packaged .tgz 2) much finer control over package.xml contents is possible There are some significant API differences. Fortunately, the most important part (filelist generation, or <contents> generation in the case of package.xml 2.0) is identical to PEAR_PackageFileManager. They could even potentially share drivers, which makes me wonder whether the drivers should be in a separate package. By drivers, I mean PEAR_PackageFileManager_File/_CVS/_SVN/_Perforce. The most important API difference is that PEAR_PackageFile2Manager extends the PEAR_PackageFileManager_v2_rw class. This means all of the low-level stuff that was handled by setOptions() in PEAR_PackageFileManager has been removed. In other words, instead of: $pfm->setOptions('package' => 'blah', 'version' => '1.0.0', 'state' => 'stable'...) you will do: $pfm->setPackage('blah'); $pfm->setChannel('pear.php.net'); $pfm->setReleaseVersion('1.0.0'); $pfm->setAPIVersion('1.0.0'); $pfm->setReleaseStability('stable'); $pfm->setAPIStability('stable'); There are twice as many calls to setting version/stability only to match the tags in package.xml 2.0. This change will affect packages like PEAR_PackageFileManager_Gui_Gtk only that instead of using getOptions(), you will retrieve the values individually using the API from PEAR_PackageFile_v2 (like $pfm->getPackage(), $pfm->getVersion(), etc.) Instead of a single call to $pfm->writePackageFile(), the setup of package.xml file and the contents can be manipulated. old way: $pfm->setOptions('installas' => array('file.php' => 'file2.php')...); $pfm->writePackageFile(); new way $pfm->generateFileList(); $pfm->setInstallAs('file.php', 'file2.php'); $pfm->writePackageFile(); I am debating the merits of providing a gigantic array-based setOptions() like in PEAR_PackageFileManager as an alternate way to do this. The main reason I think the new way may be better is that most editors nowadays have autocompletion features, making remembering the syntax for setting up things far easier than trying to set up a massive associative array. Your input will help decide whether this is actually true for you enduser types. The other thing that PEAR_PackageFile2Manager will support is easy subpackaging (details to be worked out), easy compatible package.xml 1.0 generation (details to be worked out), easy generation of bundle/php extension package.xml For the subpackaging support, I am imagining something like setting up a PackageFile2Manager object that only includes files in the subpackage, and just passing it into the parent packagefilemanager like so $pfm->addSubpackage($subpfm); $pfm->generateFileList(); This would auto-ignore the subpackage's contents when generating the parent package.xml. for package.xml 1.0 support, all you would need to do is specify a few options and it would automagically create the compatible package.xml 1.0. I like this way of doing things (package.xml 2.0 downgrade to 1.0) because 2.0 can support a larger set of possible packages and it's easier to magically cut away than to add. $pfm->createCompatiblePackagexml(array('include' => array('specificfile.php'), array('ignore' => 'anotherspecificfile.php'))); Greg