PEAR2 in CVS

Hi, I just committed the first draft of PEAR2 installer code to CVS in pear-core/PEAR2. pear-core/PEAR2/test.php is the working sample installer, it can be used to install the PEAR package if you hand-adjust the paths. Since PEAR2 is still very much a work in progress, it requires PEAR1 for a few things to function (very few things). I will be working on a roadmap that can be used to define the work schedule for any who would like to help volunteer to make this one happen. New design features are very similar to what I proposed in my message "beginning plannings for PEAR for PHP6" (http://article.gmane.org/gmane.comp.php.pear.core/4803). For instance, the reliance upon users to either define __autoload() or to require all needed files is implemented. Here's some more stuff 1) configuration Configuration is split into installation-specific variables and user options. The configuration is stored as xml and accessed using simplexml (perfect use for simplexml). Channel-specific configuration is removed, as are layers - layering is done in the registry now. Configuration path setup looks like: .config [xml file] php_dir.txt [contains php_dir value] data_dir.txt [contains data_dir value] ... .configsnapshots/ [snapshots at installation time] configsnapshot-YYYYMMDD.xml The configuration snapshots allow us to more easily move a complete PEAR repository to another directory, and also provide a kind of history of configuration changes 2) registry The registry is stored redundantly as an sqlite database and the original package.xml/channel.xml files used for installation and channel discovery. With the package.xml files and the configuration data, it is possible to completely reconstruct a damaged sqlite database file, and will also make it easier to debug a weird installation error caused by a faulty package.xml setting. Other enhancements: - On windows, COM is used to grab the application data directory for the current user, and by default the user configuration is saved there, just as it is saved by default in home directory on unix. - file transactions are customizable in much the same way as custom file roles/tasks, and split off into a separate file such that it could be released as its own package if wanted - API hides detail while allowing complex operations to be accomplished with simple and flexible code. - [not yet implemented] PEAR will be tightly linked to include_path, so that installation will assume include_path represents a chain of PEAR repositories and it will search for a "parent" PEAR repository when installing a package. This means, for instance, that if Console_Getopt is installed in the "parent" PEAR repository, it will satisfy dependencies when installing into the local PEAR repository. The risk, of course, in this case is that the dependency is 1-way: Console_Getopt can be uninstalled from the parent repository and it will break the child repository, so it will be possible to disable this by passing in an include_path value to use or php.ini to use - [not yet implemented] PEAR will be able to install packages distributed as phar archives, allowing libs to be distributed that run out-of-the-box for trial purposes without needing installation - [ultimate goal] packages can be downloaded and extracted using tar/gz or zip, and used, then at any time, upgraded using PEAR with 2 simple commands: pear repair pear upgrade PackageName This will allow PEAR to compete successfully with unzip-and-go as it will provide all the benefits and none of the annoyances of PEAR1.x Greg