Re: PEAR2 standards: anything good at all?

Hi, Christian Weiske wrote:

Now another "problem" is that PEAR installation is not relocatable. Since we already covered unzip-and go, let's presume that we are talking a real installation here. The proposed solution is to have a data_dir.txt file in the installation root that'll contain the name of data directory. Nice. But if I relocate the installation, will the file automagically contain the name of the dir I relocated to? No? So, is there a huge difference between editing this file by hand and doing a mass search-and replace that's required now?

You misunderstood the concept of the new data_dir: There is not a single file containing its name.

Excuse me? Right in "PEAR2 standards" [1] page, under "Data files": "package.xml replacement tasks should not be used to retrieve path locations, instead use the <role>.txt file located in php_dir, so if you need a data file, you do this:" and then goes the example with data_dir.txt.

It is assumed by the packages that you can reach it via dirname^x(__FILE__) calls directly above the current root php files location. Currently, you can set php files path to /usr/share/pear/php/ and data_dir to /home/tmp/some/weird/setting/ and thus need PEAR_Config to retrieve data_dir.

So you want to reduce the flexibility of PEAR to set such directories? What happens to e.g. packages that want to use "web" role or want to put binary files to directories in system path?

In PEAR2, it is proposed that php and data_dir are children of the same directory, tied together, making it unneccessary to use PEAR_Config at all. If you care about not having another PEAR_Error, you probably want to get rid of PEAR_Config for standard tasks, too.

I don't have a problem with PEAR_Config (other than it can be made a wee bit more lightweight), PEAR_Error, on the other hand, is a convoluted and error-prone way of doing common task. [1] http://wiki.pear.php.net/index.php/PEAR2_Standards