going away present

Hi all, I'm on my way out the front door to a vacation in Paris on Sunday, but as a going-away present to you, the PEAR developers, I thought you might like to know that progress towards completion of package.xml implementation has been moving along at a good clip. First things first, custom file roles can be added to the installer now. I have not yet had the time to brain my way around all of the ways this could be abused, so don't consider the implementation to be final by any stretch. A custom file role can also add configuration variables. This will allow, for instance, an app to add a custom role for files that contain database definitions that are modular in some way, so that future upgrades can automatically update things. Other examples include defining some kind of htdoc role like what was toyed with earlier in the year. The main point is that none of these roles will be required, and the default roles still work just great as they always have. Also, none of this applies to package.xml 1.0 - this format is set in stone. Only package.xml 2.0 releases can use new custom file roles. In addition, an application CANNOT define a role in its own package.xml and then use it. The role must have already been installed by a separate package, meaning users can't inadvertantly install a new role by installing "DB", unless DB contains a role that it doesn't use. There will probably have to be a strict check on files to see if they install into the PEAR/Installer/Roles directory, and if they do, perhaps installation could automatically fail without an explicit command-line switch. This way, users can't even accidentally install a role they don't want to. More thought needs to be done along these lines. I've also added but not yet implemented the exciting new "package" role, which allows a .tgz to be directly bundled, and installed along with a package. It makes installing without internet very straightforward. Second things second, I've expanded the age-old <replace> tag to be a whole subset of tags called "tasks" a-la-Phing. These are not as versatile as Phing tasks, in the name of keeping things both simple and secure. However, the implementation makes doing both pre- and post-installation scripts a piece of cake. This implementation is far more strict than file roles, and literally prys open the files to validate the name of the single class it's allowed to contain and its methods. <file name="scripts/install.php" role="script"> <tasks:postinstallscript/> </file> this causes an error - only php roles can be post/preinstallscript <file name="scripts/install.php" role="php"> <tasks:postinstallscript/> </file> here, the installer will pry open scripts/install.php and look for a class named "scripts_install_postinstall" with methods "init" and "run". It doesn't verify method signatures, but these reasonable checks should strike out most unintentional install scripts. init is passed a PEAR_Config and a PEAR_Frontend_* object. All output for the user should be done using the PEAR_Frontend_CLI/Web/Gtk object to allow easy use for all. Even better, the postinstallscript task can use the package that was just installed! An added bonus that occurs because of the way tasks work is that you can do this: <file name="scripts/install.php" role="php"> <tasks:replace from="@version@" to="version" type="package-info"/> <tasks:replace from="@data_dir@" to="data_dir" type="pear-config"/> <tasks:postinstallscript/> </file> and the replacements will take effect before the script is called. Tag ordering is important. My thought is that a postinstallscript can be used in a package that distributes a custom file role to set up the configuration variables it creates, or for more obvious things like database creation, etc. The PEAR_Server package will be using this to help configure the channel database. So, that's the present. Application support becomes near to a complete reality with all of these features. Greg