pear list-packages and more

Hi, The first pear sub-command communicating through xmlrpc with the backend is implemented. Also, there's a simple configuration interface that lets you read and write configuration values from a system-wide file (for example /etc/pear.conf) and a per-user file (for example ~/.pearrc). Configuration data is stored as a serialized PHP array right now. How to test the new stuff: pear -d master_server=your.dev.box -s This is _supposed to_ store your configuration in ~/.pearrc (I haven't had time to test everything thoroughly yet). To update the system defaults (set the system-defined master server to pear.php.net): pear -D master_server=pear.php.net -S Also you can speficy an alternate config file with -c: pear -c ~someotheruser/.pearrc list-packages As you may have noticed, the uppercase options are for the system-wide stuff, while the lowercase options are for the per-user stuff. The old -d, -p, -e and -v options have been removed, use "-d foo=bar" instead (-d is doc_dir -p is php_dir -e is ext_dir and -v is verbose). These options can be set in the system and user config files too. Finally, there's a mechanism to call "any" xmlrpc method in the pear script now: the PEAR_Remote class. Here's how to use it: $config = new PEAR_Config; $remote = new PEAR_Remote($config); $result = $remote->call("package.add", $my_package_data); This is actually equivalent with running this code on the server: $result = package::add($my_package_data); The rest is taken care of by the xmlrpc layer. There's just one thing you need to be aware of, and that is if you are passing date or binary data parameters to PEAR_Remote::call, then you need to use xmlrpc_settype on those fields first. Shouldn't affect much though. - Stig