A new entry has been posted to the PEAR blog with the latest minutes for the group's July 13th meeting.

Some highlights from the meeting include new/upcoming RFCs for package naming schemes, exception handling in PHP 5.3, and a vote on extending the current PEAR2 Policies. Heavy stuff, check it out!

You can check out the full notes here on the PEAR portion of the PHP.net wiki.

Joshua Eichorn has blogged about three new projects he's added to the PEAR2 repository:

• COnsole_CommandLine - a port of the PEAR1 console package
• Template_Dwoo - a Smarty-compatible template engine
• template_engine - a simple templating engine (and the example package for namespace usage)

Not really what I expected to be the first round of new code, but its nice to be setting up access for people. Oh and remember PEAR2 is targeted at php 5.3 but not everything is namespaced yet since not everyone wants to run snapshots of php for development.

You can find more of the packages on the PEAR2 svn repository.

Travis Swicegood has made a new release of the successor to the PEAR RunTest package for PEAR2 - the new PHPT.

Since this is usable and PEAR2 is still being worked out, I've decided to release this as a standalone package for the time being with the intent of bundling it with Pyrus or including it directly in PEAR2 when PEAR2 is realized.

This provides the majority of the functionality provided by PEAR's pear run-tests command via its own phpt command and it can even provide pear style output.

Examples of its use are included as well as the method to download this latest version (via a PEAR channel, of course) or through the package's web page. Issues found with the software can be posted to the project's Google code page.

Though there's no slides for his unconference PEAR2 talk, Joshua Eichorn has posted some of his planned features for the update to the popular PHP package repository:

I do have a list of new features planed(or already implemented) for the Pyrus installer.

The list includes:

• no installation necessary. It runs out of the box as a .phar. No go-pear.phar needed
• Pyrus is much more development/production-oriented, and will have a "deploy" command for managing deployment of development code to a production server
• out-of-the-box supported packaging formats include .tar, .tgz, .tbz, .zip, and .phar
• PHP 5.3+-based code means it fully utilizes cutting edge PHP features such as SPL iterators, XMLReader/XMLWriter, ZIP extension, phar extension (if enabled), exceptions
• full application support is available with the new www and cfg (configuration file) roles

Check out his post for more items on the list.

Greg Beaver talks about a big push that he's making towards PEAR2 by working hard on an integral piece of the puzzle - the Pyrus installer.

I'm churning out code to turn its installer, Pyrus, from vaporware into actual code. Along these lines, there has been significant progress. The code has been developed on PHP 5.2, but will most likely target PHP 5.3 with the introduction of namespaces. Pyrus completely revamps the way things are done.

Greg mentions some of the functionality the installer will use including XMLReader/XMLWriter, namespaces and bits of functionality from the Standard PHP Library (SPL). He's released what he's developed so far via a PEAR channel with no other dependencies.

On the PEAR blog today, they're asking for thoughts on some of the standards for the coming PEAR2 development environment:

Please read the following document and post your comments on the wiki using the discussion page. Comments are opened for a period of two weeks. It is very important that you comment as these standards will define PEAR2.

The standards can be found here and include everything from the base requirements and package approach down to specific package-related rules (for things like directory structure, class-to-file conventions and handling dependencies).

Along with a few personal comments, Lukas Smith has posted some thoughts about the state of everything PEAR following his stepping down from working as an active developer on the project.

I guess with me and Pierre leaving it did spawn a lot of energy about how to organize PEAR in the future. I am still participating in this discussion to some extent, mainly functioning as the historian who can explain why things are the way they are etc in order to prevent people from making rash decisions or even worse repeating old mistakes.

He also comments on the state of package submissions to PEAR, noting that some of them are just unrealistic and that it might be better to start a "PEAR2" side to allow for some of these more expanded ideas to flourish.

Instead I think each of the categories should manage itself more. So packages approval would be handled within the category. The same for QA'ing etc. This way new developers would not be facing this gigantic community. I think this is simply overwhelming. Even for old developers it becomes impossible to feel "at home" in a project of the size of PEAR.