one real-world example of how removing replacements simplifies PEAR

Hi, I thought it might be useful to examine another real-world example to understand the logic behind the PEAR2 proposal. One issue raised by removing replacements is applications that provide scripts. A replacement to scripts_dir and php_dir config variable is invaluable for making things like PEAR's "pear" command "just work" and is much more difficult to do without replacements. phpDocumentor has solved this using another package.xml feature, the <install as=""> tag and <ignore> tag. We provide two copies of the phpdoc script, one designed for unzip-and-go that tries to search for php and do other magic, and one designed for installation via pear that uses a replacement and is only a few lines long. The PEAR phpdoc is zipped up as pear-phpdoc and the unzip-and-go phpdoc is zipped up as phpdoc. On installation by the PEAR installer, pear-phpdoc is installed as phpdoc, and the unzip-and-go phpdoc is ignored. This system works nicely. For a while, I was doing the same thing with two copies of PHP files, but this became onerous. Instead, we now use clunky looking tests like: if ('@data_dir@' != '@'.'data_dir') { // installed by PEAR } else { // unzip-and-go } This works, but elicits lots of "what the crap is that" from users trying to track down bugs they encounter, and also makes maintenance more difficult (sorry Chuck). The PEAR2 proposal would completely eliminate the above confusion, resulting in a single line of code for loading data files that works independent of whether it was installed by Pyrus or just unzipped. This ultimately makes the code for applications more maintainable as well as more useful. Most libraries do not provide scripts, but the change for libraries is also quite small: with PEAR/PEAR: file_get_contents('@data_dir@/PackageName/data/file.txt'); and with PEAR2/Pyrus: file_get_contents(dirname(__FILE__) . '../../../data/pear2.php.net/PackageName/file.txt'); There are of course ways to optimize this, perhaps defining a constant with the path to the data once at startup, or other tricks, but it's still a one-liner at the important point of loading the data file. On an unrelated note, data_dir and company will also support baseinstalldir, eliminating that annoying extra "data" between PackageName and file.txt, but this will happen no matter what, and is not a structural issue. Greg