Re: PEAR2 in CVS

Lukas Kahwe Smith wrote: > Greg Beaver wrote: > >> - [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 > > this one will be tricky to get right and even trickier to communicate to > users. as such it should definitely be off by default. people should > explicitly have to enable it. The explicit linking of PEAR to include_path I think should stay on by default - but only to the first repository detected. In this way, people can use PEAR without configuration, a la OS X making reasonable assumptions that can be easily changed. Allowing multiple repositories should definitely be controlled. I think this could be added as a "system" level configuration variable (explicitly specified in the repository .config file) and it should clear up any voodoo problems. > as i noted on my email to pear-dev about the Doctrine base class, we > should provide an sample autoload implementation. where should it be? > should be try to separate any new base classes in PEAR from the > installer? should we even start thinking about renaming the installer so > that we reduce some of the confusion over what PEAR is (installer, base > class, a repository)? PEAR2/Autoload.php provides the autoload function for PEAR. PEAR2/test.php uses it as such: require 'PEAR2/Autoload.php'; function __autoload($class) { PEAR2_Autoload($class); } I think that will work for the majority of users, seeing as it is 4 lines and works in all cases for the large tree of the PEAR2 Installer. As for renaming the installer, +1 million. I have been playing around with analogies to PEARs in real life, as in PEAR2_Pollinator, PEAR2_Planter, and others like PEAR2_Chef. More radical would be to change the name PEAR to Pyrus (genus of PEAR) so that all packages for PEAR2 are prefixed with Pyrus_. Any other ideas are appreciated. Thanks, Greg