Composer exists to overcome the problem [with PECL and PEAR being system-wide], composer is a dependencies manager that come in a form of command utilities, composer make it possible to 'plug and play' PHP packages across application no matter what frameworks we are using as long as the packages follow the shared format. With composer we can define our project dependencies simply in a 'composer.json' file, and later on we can install and update these dependencies automatically.

He introduces the Composer tool and then shows how to set it up via the Windows installer (with screenshots). There's two ways to set it up - "Basic" that does the install in one project and "Global" that installs it somewhere outside of the current project, available to all projects.

There has been a trend in the last while for various bits of useful software to have a one-line shell command recommended as the installation method. The usual form of this is to pipe something like curl or wget to some interpreter, be it bash, php, ruby, or some such. [...] This [type of] command takes the output of curl and pipes it straight to bash. I have several issues with this.

His three main points center around the fact that you cannot inspect the code before executing it with this method, that you can't verify the source of the code and that it teaches users bad habits of trusting in "magic commands" like these.

As with most tools that work really well, I know very little about PEAR. I mean, I use it all the time, and I love it for getting all the extensions installed that I need for the work I do. [...] However I'm now in a situation where I might need to install PEAR packages with a connection that may or may not be working, and I'm not sure exactly which packages I might need, so I wanted to know whether I could use PEAR as my packaging tool even when I wasn't able to reach the usual channels. And guess what? I can!

The install is a pretty simple two-step process - just download the package(s) you'll need for your development and point the PEAR installer (you'll need this installed first, obviously) at the archive file. It's smart enough to take care of the rest.

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.

Apple computers and OS X are quite common here at Liip (and local.ch) as developer machines. But while OS X comes with a not-too-old PHP installation, it nevertheless doesn't have everything we need (for example the infamous intl extension) and it's not that easily extendable with self-compiled extensions. [...] Our friends at local.ch took this very dissatisfying situation in their own hands, forked the build-entropy-php script from Marc Liyanage's great entropy work, extended and adjusted it to their (and our) needs.

If you'd like to try out the package on your own systems, you can find it and the full instructions for its use at http://php-osx.liip.ch/. He also points out the actual build part of the process (build-entropy-php) as well as the packager you'll need for it to grab the library updates it needs.

The new dependencies of the PHPUnit package, such as PHPUnit_MockObject for instance, are installed first. The PHPUnit package itself is installed last. And herein lies the problem: PHPUnit_MockObject installs the new version of MockObject/Generator.php before the PHPUnit package is upgraded. This upgrade deletes the MockObject/Generator.php file as it previously belonged to the PHPUnit package.

He includes two complete file listings showing the difference in the structure before and after the upgrade. The PEAR installer is at fault due to a misunderstanding it has about where the MockObject/Generator.php file belongs. The only way to fix this, currently, is to force install the new subpackages instead of just an update - DbUnit, PHPUnit_MockObject and PHPUnit_Selenium. Instructions and a resulting files tree are included so you can insure your install is correct.

Half a year after I collected requirements for a generic PHP application installer, Kore already implemented the first bits of it for the Arbit installer, which is supposed to be generic enough for other PHP applications, too. He also held a talk at the PHP Unconference in Hamburg, collecting more requirements for it. There is already some code in arbit's svn repository which at least generates a .phar file that checks your application requirements and collects configuration options.

An example of a simple build is included that will create the Arbit installer package that, when executed, will give a basic configuration screen. They suggest making .phar files executable by the web server too (interpreted by PHP) just to make things simpler.

The Windows Azure Command Line Tools for PHP are now available in the Microsoft Web Platform Installer (Web PI). This announcement was made on the Interoperability Team blog as part of a post that outlines interoperability elements of a cloud platform. The entire post deserves a close read, but I'm initially most excited about this small piece of the announcement.

This small piece talks about this latest tool release that can be installed directly from the WebPI installer under the Developer Tools section of the interface. You'll still need the Azure SDK to use the tools, but if you don't have it the WebPI installer will download and set it up for you. You can find more info about them here.

After a quiet holiday season, the PEAR community has started rumbling again. [...] If this level of activity is anything to judge by, the future of PEAR looks bright for 2010!

Updates this month include a mention of the PEAR project on digg.com, the release of several new package versions for things like Facebook and the Mail package. They've also set up a continuous integration environment to help make the maintenance and testing of the code in the new releases simpler. There's also mentions of Phirum and PEARFarm and how they're lowering the barrier for PEAR installation everywhere.

First of all, yes the presented solution was somewhat complex, partly because it is still a proposed idea and definitely up for optimizations. However I am still very convinced of my approach, something I should discuss in more detail.

He mentions some of the downfalls that PHP applications have had up until now as far as ease of deployment and the maintaining of dependencies. Most of the suggested solutions aren't optimal, so a system using the PEAR installer would have to overcome some of them and keep it simple to use. Benjamin has taken the PEAR installer and laid his new Pearanha tool on top of it to help you create custom PEAR installer scripts.