In this latest post to his blog Phil Sturgeon looks at how to use the Composer package management tool to install packages directly into your CodeIgniter applications.

If you want to start using Composer components in your application there is no reason why you should not. The code is mainly PHP 5.3 but by slowing moving the majority of your application from framework specific code to generic packages that work in any framework you free yourself from being limited to a specific framework and will find a transition to FuelPHP 2.0, Laravel or Symfony2 much easier in the future.

There's four steps to his process (most of them the usual Composer setup ones): install Composer, create the "composer.json" file, install the needed dependencies and then include_once the Composer autoloader.

Henri Bergius has a new post to his blog showing you how to use the popular Composer package management tool to manage dependencies in Heroku applications.

While Heroku got its start from hosting Ruby on Rails applications, it nowadays supports many different environments in the Cedar stack. Node.js is what many use, but they also do support PHP. Dependency management is easy for Node.js applications as Heroku recognizes your package.json files and automatically installs the libraries needed via NPM.

Until now PHP developers haven't had this convenience, but as Composer is emerging as the default PHP package manager, I've now added support for it. Before the pull request gets accepted, Composer dependency handling can already be used by specifying my custom PHP buildpack when creating Heroku apps.

He shows you how to get it up and running with a sample application - creating the new git archive, creating the Heroku app with the custom backapack (and a "composer.json" file), setting up the main "index.php" file and push it all to Heroku. You can view his sample application here (a simple URL encoding form).

Rafael Dohms has a new post sharing the results of one of his recent struggles - getting a Symfony2 application deployed to the PagodaBox service using Composer to manage the packages. In the post he details each step of the process.

I have been working on a little pet project and wanted to put it up somewhere to show to a few people how it was going. I wanted something really simple so I decided to give the PHP PaaS solutions a try. Its a very simple Symfony 2.1 based app using Composer for vendor management, so I went on a quest to see what could be done and how.

He shares the contents of his Boxfile (a special file PagodaBox uses to configure your application) with entries for writeable directories, extensions to load and the database configuration. He found that, during deployment, everything is writeable by the "build" user, so there's no worries about installing Composer dependencies.

Stefan Koopmanschap has a quick new post to his blog with a handy tip for Composer and Cilex/Silex users when dealing with custom namespaces.

For a new proof of concept application I'm building, I need both a simple web interface as well as some commandline tools. I decided to use Silex for the web interface and Cilex for the CLI tools, and opted for using Composer for installing these dependencies into my project. I ran into some issues with the custom project libraries I was building for this application however. Registering my custom namespace into Silex and Cilex didn't result in the classes being loaded for some reason. Composer helped me out though.

His solution involves letting Composer be the default autoloader for the application via an "autoloader" configuration option in the "composer.json" (that can also take a classmap option if you're not PSR-0 compliant, see here).

On DZone.com there's a new post from Giorgio Sironi about using Composer to install packages/libraries:

The main package source used by Composer seems more similar to the usage of git submodules at a first glance: a list of dependencies on other projects is specified and stored under version control, and upon a checkout these projects are grabbed directly from their repositories.

He talks about what problem the project solves, what issues he's found with it so far (the amount of stuff downloaded for each dependency, the single point of failure of the one Packagist repository) and shows how to get it installed and creating a sample "composer.json" file for an example project.

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.

On the Nelm.io blog today there's an update about Composer, the PHP package manager that's been steadily growing in popularity over the last few months.

This weekend we have been busy hacking on Composer in our office together with Nils Adermann and Volker Dusch. We wanted to push the project forward a bit faster than the odd free evenings usually allow, and I would now like to introduce the changes we made.

Their updates include mentions of:

• Changes to the "dev" version handling
• Major bugfixing in the dependency resolver
• More project documentation
• GitHub integration with Packagist (allowing you to directly update the Packagist site when you push a new version)
• A cleanup on the repository creation process (see here)

One of the more popular PHP microframeworks right now is Slim and Chris Hartjes has a new post to his blog about a good way he's found for organizing applications that use this handy tool.

I've never really used a microframework in PHP before. I used Flask for a Python project that I did to experiment with using Google App Engine. The principles seem to be quite similar (although I will admit that having decorators in PHP would be ineresting) but the trade-off with a microframework is that you usually have to figure out an application layout for yourself.

He also uses the Pimple dependency injection container, Twig templating and Composer for package management. He describes how he got it all set up - organizing the code so Composer could understand it, creating the Twig templates directory and creating some of his default routes.

Alessandro Nadalin has a new post to his blog looking at the Composer project and using it to manage packages and dependencies in PHP applications.

Managing dependencies between pieces of software, in PHP, hasn't always been a relief: we had PEAR and PECL with their workflows and problems while, in other ecosystems, the solution to this problem has been solved in better ways, like NodeJS's NPM.

He takes a first look at the tool, describing how to get it set up, create a sample configuration (describing each section inside it) and an example of the tool's output. He also briefly touches on the Packagist website/repository and links to the instructions on how to create your own.