The rise of Composer and the fall of PEAR

Fabien Potencier

May 05, 2014

A couple of months ago, Nils Adermann sent me a nice postcard that reminded me that "3 years ago, we [Nils and me] met for the SymfonyLive hackday in San Francisco." Nils was attending the Symfony conference as he announced the year before that phpBB would move to Symfony at some point.

At that time, I was very interested in package managers as I was looking for the best way to manage Symfony2 bundles. I used PEAR for symfony1 plugins but the code was really messy as PEAR was not built with that use case in mind. The philosophy of Bundler from the Ruby community looked great and so I started to look around for other package managers. After a lot of time researching the best tools, I stumbled upon libzypp and I immediately knew that this was the one. Unfortunately, libzypp is a complex library, written in C, and not really useable as is for Symfony needs.

As a good package manager to let user easily install plugin/bundles/MODs was probably also a big concern for phpBB, I talked to Nils about this topic during this 2011 hackday in San Francisco. After sharing my thoughts about libzypp, "..., I [Nils] wrote the first lines of what should become Composer a few months later".

Nils did a great job at converting the C code to PHP code; later on Jordi joined the team and he moved everything to the next level by implementing all the infrastructure needed for such a project.

So, what about PEAR? PEAR served the PHP community for many years, and I think it's time now to make it die.

I've been using PEAR as a package manager since my first PHP project back in 2004. I even wrote a popular PEAR channel server, Pirum ( But today, it's time for me to move on and announce my plan about the PEAR channels I'm managing.

I first tweeted about this topic on February 13th 2014: "I'd like to stop publishing PEAR packages for my projects; #Composer being widespread enough. Any thoughts? #Twig #Swiftmailer #Symfony #php". And on the 14th, I decided to stop working on Pirum: "My first step towards PEAR deprecation: As of today, #Pirum is not maintained anymore. #php"

As people wanted some stats about the PEAR Symfony channel, I dug into my logs and figured out that most usage came from PHPUnit dependencies: "Stats are clear: my PEAR channels mostly deliver packages related to PHPUnit: Yaml, Console, and Finder. /cc @s_bergmann".

On April 20th 2014, Sebastian Bergmann started the discussion about PEAR support for PHPUnit: "Do people still install PHPUnit via PEAR? Wondering when I can shut down". I immediately answered that: "If @s_bergmann stops publishing PEAR packages, I'm going to do the same for #symfony as packages were mainly useful only for #PHPUnit".

And the day after, Sebastian published his plan for deprecating the PHPUnit PEAR channel: "So Long, and Thanks for All the PEARs:".

More recently, Pádraic Brady also announced the end of the PEAR channel for Mockery.

Besides Symfony, I also manage PEAR channels for Twig, Swiftmailer, and Pirum. So, here is my plan for all the PEAR channels I maintain:

  • Update the documentation to make it clear that the PEAR channel is deprecated and that Composer is the preferred way to install PHP packages (already done for all projects);

  • Publish a note about the PEAR channel deprecation on the PEAR channel websites (already done for all projects);

  • Publish a blog post to announce the deprecation of the PEAR installation mechanism (Twig, Swiftmailer, and Symfony);

  • Stop releasing new PEAR packages;

  • Remove the PEAR installation mechanism from the official documentation (probably in September this year).

Keep in mind that I'm just talking about stopping publishing new packages and promoting Composer as the primary way to install my libraries and projects; the current packages will continue to be installable for the foreseeable future as I don't plan to shut down the PEAR channels websites anytime soon.

On a side note, it's probably a good time to remove PEAR support from PHP itself; and I'm not sure that it would make sense to bundle Composer with PHP.

Happy Composer!


gravatar Andy Thompson  — May 05, 2014 12:25   #1
It's a bit disappointing Composer is still in alpha. It'd be good if it could be made to release before removing PEAR support.
gravatar Dayson Pais  — May 05, 2014 12:48   #2
While Composer may technically be in Alpha, I doubt anyone treats or uses it under that consideration today.

Its the clear de-facto. Bye bye Pear.
gravatar Zarko Stankovic  — May 05, 2014 12:51   #3
Good news!
I think that it'd be nice to bundle Composer with PHP (the same thing happened to npm with Node.js).
gravatar Marco Pivetta  — May 05, 2014 13:13   #4
Note that Doctrine Project dropped PEAR support since the release of doctrine/orm 2.4, which was almost a year ago :-)

No regrets, much less to handle (in tutorials, in deployment/releases, in helping users, in bugs).
gravatar Benoît Merlet  — May 05, 2014 14:09   #5
You mentionned libzypp and the fact it has been ported to PHP.

How much work would it be to write a PHP extension in order to get better performance with Composer?

As far as I understand the situation, the bottleneck is the SAT solver and I know work has been done to provide a C library just for that. See [] and [].
gravatar Eduardo Casas  — May 05, 2014 15:54   #6
A step forward. This was gonna happen sooner or later.
gravatar Cary Gordon  — May 05, 2014 17:19   #7
Promoting Composer would be a great move, but not until it is at least in beta. While folks might be treating Composer as a released product, they do this at considerable risk.

A better approach would be for more of us to get involved and help move the project forward.
gravatar Luis Cordova  — May 05, 2014 17:48   #8
I am just a bit preocupied that composer was too silent as to where it was getting its guidelines, now we know. But maybe it could have done more good to publish that it was a port of that other project.
gravatar Jeremy Lindblom  — May 05, 2014 19:13   #9
The AWS SDK for PHP will also be ending PEAR support at some point this year (probably EOY). Not having to build and deploy PEAR channels will be a relief.
gravatar Sebastiaan Stok  — May 06, 2014 11:32   #10
@Luis: - "This project's Solver started out as a PHP port of openSUSE's Libzypp satsolver."

Composer is (unlike Pear) very easy to install, so bundling is not necessary to get it widespread. But mentioning Composer in the readme of PHP or on the website of would help.

I actually only ever used PEAR for installing PHPUnit which was not always that easy.. Adding channels, installing, getting past the countless of complaints of stability to low, ugh I glad that time is over.
gravatar Yasmany Cubela Medina  — May 13, 2014 05:47   #11
It's really a great news. Its time composer get the place it owns as package manager in php projects and libs.

I always thinks that pear was a needed tool to install libs but not a definitive solution, have too many steps, get to many errors.

The new ones need an easy to install and use package manager for php over multiplatform. For developers an structured and well defined way to specify requirements, dependencies; composer do that, maybe need some refinements but do hes jobs in a very good way i think.

Also big companies as facebook and google feel confidence on composer and move their apis releases over composer, that should count.

So great job Nils/Fabien