Stuart Herbert has a new post today showing how to get the well-established PEAR package management system working on Windows 7 so you can easily call "pear install" on whatever your needs might be.

So that I don't forget how to do this next time around. Worked for me, your mileage may vary. First step is to get a working install of PHP. [...] At this point, you should be able to open up a Command Prompt, and type 'php -v', and see the response 'PHP v5.4.latest …' appear as expected. Now for PEAR itself.

He gives step-by-step instructions on how to get PEAR up and running - downloading and configuring it with the correct Windows-based paths and using the PEAR_ENV.reg file to update your registry.

In this new post to his blog Phil Sturgeon talks about what he (and apparently several others) think is the "way forward for PHP" to make it a better language and ecosystem - packages.

What is a package? A package is a piece of reusable code that can be dropped into any application and be used without any tinkering to add functionality to that code. [...] Most package systems also allow for something called dependencies. [...] This is how most modern programming languages work, but to make a generalisation: PHP developers hate packages. Why? Well while other languages have great systems like CPAN for Perl, Gems for Ruby, PIP, PHP has had a terrible history with package management going back years.

He talks about one of the main current packaging systems, PEAR, and how, despite its attempts, it just hasn't seen the adoption the package management of other languages has. Phil makes a recommendation that is slowly becoming more and more popular in the PHP community - building "unframeworks". These sets of reusable components (similar to the ideas behind Aura, Symfony and Zend Framework 2) are designed to be dropped in and used without the dependencies of the frameworks they live in. He points to the Composer/Packagist dynamic duo as a way through all of the current packaging issues - a simple way to make any project an installable package just by adding a configuration file.

In a new post to his site Till Klampaeckel shows how to use PEAR and composer resources (two popular PHP package management tools) from inside of a chef deployment script.

This is something experimental I have been working on for our chef deployments. So the objective was/is to find a sane way to install PEAR packages and install dependencies with composer.

He shows how to set up the configuration script to discover a new PEAR channel, make the chef script not "fail hard" if a command returns a failed response code (as PEAR will do if the channel is already discovered). The "ignore_failure" configuration directive comes in handy for this. He also shows how to implement a LWRP in chef for both a PEAR and Composer resource.

You can find the code for this and other cookbook examples on his github account.

Building on the graphing tutorial in his last post Sameer continues on looking at graphs in PHP with this new post showing how to create an "agency matrix" of a currently built graph.

Building a graph is not enough; we also need the ability to search through it. To make it easier to build search algorithms, it is useful if we can represent the graph and its connections in a different way; adjacency matrix being one such representation. An adjacency matrix is a means of representing which vertices (or nodes) of a graph are adjacent to which other vertices.

He includes some sample code to extract the data from a graph (built with the PEAR Structures_Graph package) and create a basic "table" of information about each nodes' connections.

In the latest post to his blog Sameer Borate takes a look at using the Structures_Graph package from PEAR to create data structures in PHP with linked nodes for directed and undirected graphs.

The Pear Structures_Graph package allows creating and manipulating graph data structures. It allows building of either directed or undirected graphs, with data and metadata stored in nodes. The library provides functions for graph traversing as well as for characteristic extraction from the graph topology.

After sharing the one-line install, he shows how to create some instances of the package's Nodes and how to connect them to a graph and link them to other nodes. He includes a few examples - a simpler one with multiple nodes joined in a directed graph, another showing how to associate data with a node and how to query the graph for node connections and testing to see if the graph is acyclic.

Mike Wallner has shared a quick and easy HTTP caching technique in a new post to his blog today. The key is in using the PEAR HTTP_Header package.

Ever watched youself browsing e.g. a web forum? Noticed that you viewed the same page several times? Well, this means extraordinary and useless load for your server if there's no caching mechanism implemented in the web application. Even if there is some file or db cache you can still improve performance with implementing some http cache.

With a few simple lines of code using HTTP_Header, you can tell your scripts how long to set the "expires" header to on your requests. This increment (in seconds) is relayed to the browser to tell it when to next fetch the page and not reload from cache.

Mike Purcell has a new post to his blog showing a method he's followed to be able to use the popular PHPUnit unit testing software without having to go through the PEAR installer to get there.

PHPUnit is a great tool to protect us developers from introducing new defects when adding new features or re-factoring code. However there is one HUGE downside to PHPUnit; it must be installed using PEAR. Personally, I don't like 'auto-installers', I'd prefer to know what exactly is happening behind the scenes with regards to which libraries are required and how they are being called. [...] After breaking down the PHPUnit source code, I realized it could be installed without going through PEAR, and without too much headache.

He walks you through the directories you'll need to set up (test/vendor), the commands you'll need to get the latest version and unpack it, changes to set up some symlinks and updating the PHPUnit source to modify the autoloader, bootstrap and phpunit executable.

On the PEAR blog today there's an update about the migration over to github that 5 million lines of code has already made:

Since October 2011, 5 million lines of the PEAR codebase has shifted to github. Hand in hand with this shift has been the tireless work of Daniel C - someone who brazenly said "I will fix the failing packages!" in the tail end of last year.

As a result of his efforts a list has been created of known good packages to use with PHP 5.4. Other results include:

• All test infrastructure upgrading to PHP 5.4 release candidates
• All database driven test suites executing properly, catching a variety of simple bugs
• Hitting a point of "near zero" patches to be applied to unmaintained packages
• Increasingly, the PEAR QA team is delivering PHP 5.3+ friendly forks of existing packages

On the PEAR Group blog there's a new post welcoming all new contributors to the project and pointing out that the PEAR account on Github has officially passed the 200 repository mark in the move from SVN to Git.

PEAR is about providing the PHP community with reusable, effective components - this has been our mission since day 1. If there is anything we can do to make that goal happen, to assist you as an individual or company, I would strongly encourage you to let us know - we're here to help.

They mention the work of two individuals that have done good work on a specific package, meldra and Gemorroj - perfect examples of how the move to Github has made it simpler to implement changes that have been "waiting in the wings" on the XML_Feed_Parser and Image_Barcode2 packages.

If you've had changes you've wanted to make to a PEAR package in the past but haven't ever gotten them submitted, there's not a better time than now.

If you missed out on the Future of PEAR/Pyrus webcast event put on by Engine Yard, you're in luck - they've posted a recording of the event.

In this panel discussion, we tackle topics including the direction PEAR and Pyrus will be going in the next few years, obstacles that may be on the horizon, and more.

PEAR is the package library of standardized packages for a variety of common development tasks. Pyrus is a new package manager to make installing and maintaining PEAR packages simpler. Engine Yard's next webcast will cover the Lithium framework with core contributors Nate Abele, Garrett Woodworth, and John Anderson on December 1st.