Packages: The Way Forward for PHP

Posted: 2012-03-06
Category: PHP

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. You don't need to know what is happening inside, only what the API for the class(es) are so that you can archive your goal. Maybe this package uses another package, that is called a dependency.

Most package systems also allow for something called dependencies. This will basically allow "Package A" to sit on top of "Package B". What is great about this is that if I want to work on one chunk of code I can reuse another chunk. Instead of adding more code this can reduce the amount of extra code in your package, because "Package C" can sit on top of "Package B" too.

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.

What about PEAR?

PHP has had a packaging system for years called PEAR. Let's get this understood right off the bat:

PEAR sucks

To get code onto the main PEAR repository you need to get a certain number of up-votes, otherwise it will not be accepted. This was meant to ensure quality but has only helped to detur contributions and promote elitism.

Another knock-on effect is that you have to install pretty much any code you need to add a new repository, because so many people are using their own to avoid using the default repo. That makes it harder to search, harder to contribute and just generally more of a bitch to work with.

Of the packages already on on PEAR, most of them are massively out of date, inactive and no longer maintained, or never made it out of alpha. I have heard a few developers say "PEAR is awesome, they have a package for everything!". Maybe, but when I see that amongst a team of 4 developers, 2 are inactive and the code only got to 0.2.1 (alpha) in 2006-04-22, I am not full of hope for the stability of that codebase.

The nail in the coffin for me with PEAR is one of the biggest bug bears of the Gem system: system-wide installation. If I want to use a specific package, which requires a newer version of an already installed package, then I have to update it on my whole installation. That means an application I have not touched in weeks might break next time I try loading it on my local box. WAT?

The community gave up on PEAR

With frameworks like Ruby on Rails doing a cracking job of helping developers get things done faster, PHP frameworks started springing up.

CodeIgniter set out in 2006 suggesting it was for developers who "are not interested in large-scale monolithic libraries like PEAR". Almost instantly people were hooked. They could make an entire application with the most useful libraries guaranteed to work with their code. Everything was versioned as one, released as one and had the same team.

In a time where nobody in the PHP community could decide on a standard, PHP frameworks would each adopts a coding standard. No matter what those standards were, at least they were the same in all the classes.

CodeIgniter was not the only framework around, with CakePHP and Symfony starting out at similar times. They all had the intention of helping developers build applications without the hassle of dependencies, so people got used to building everything with a framework.

Let's all start building frameworks

Since late 2005 / early 2006 when these projects set out, hundreds of PHP frameworks have been developed by single developers, companies, community projects, everyone and their dog seems to have been involved with creating a PHP framework at some point or other, hell I've been involved in two: CodeIgniter and FuelPHP.

PHP frameworks themselves have taken some flak for building up all this new code, bundling in ORM's (I've always said ORM's should not be part of a framework), adding in their own DB abstraction layers, etc. Some see this as a barrier as to switch to a new framework means throwing out everything you know and starting again.

One problem with PHP frameworks is that when one framework doesn't do exactly what a developer wants, they either dump it and start building their own, or fork the existing one until there is no resemblence. This all or nothing approach is what has lead to our main problem: ** Reusable Code **.

Does a library written for Kohana work with CodeIgniter - which was at one point a CodeIgniter fork itself? Nope.

Does a package written for Symfony work with FuelPHP? Not even close!

Stuff frameworks, let's go native

You wouldn't be the first to suggest it. As you know, creator of PHP Rasmus Lerdorf is all about procedural code and suggested years back that you write your own basic MVC architecture and not a full "framework".

Why do that? I have to build my own code that turns a URL into a loaded PHP file, I have to sort out a configuration system, handle "templates", do a million things that I could have done in seconds with a framework. Also, when I get another developer in I love just saying "this is CodeIgniter so you know whats going on" and not spend hours taking them through all my random code, which is probably different for each project.

The MVC wrappers were never the problem here, the problem was the lack of reusable code. Classes that developers can use to build their applications quickly. For years we Googled for PHP libraries and found them from places like SourceForge, PHP Classes, Google Code but this lead to a million different coding standards, no way to get notified about new versions and was generally just a shit way to manage code.

Let's build an unframework!

This is a fun term that started sprining up with projects like Flourish and Spoon starting to build reusable components that you could drop into any application.

Thats idea is lovely and all but Flourish never made it out of BETA after years of development.

Spoon looks brilliant - mainly thanks to their shiny design - but is a one-man-army. How can we expect one guy to take care of all that code? It took a year for the developer to get from 1.2.0 to 1.3.0 which is not a speed of progress I am happy with.

Somebody is even working on a new unframework called Phrame which is only a splash page with a subscription box. Do we need more of these small-team solutions?

So… what?

Packages were never the problem. The PHP community has coded itself round in circles for years without ever actually fixing the problem and we're back where we started.

We need a better packages system. PEAR2 happened, but it still just sucks.

Frameworks have been used to the idea that they were the solution to a problem - and they are. They are fixing a lot of problems but a problem all the frameworks have been trying to fix over the last year are - wait for it… packages!

Not even Zend are using PEAR? Funny that.

These framework specific packages - espeically those with command line install / update utilities - are a breath of fresh air are and the communities are happy with the added functionality they can instantly put into their applications.

The downside is that the same code is being written over and over again for different frameworks, which is a massive waste of man-hours.

Let's take a personal example. I noticed recently that Laravel has a OAuth2 Bundle, which was forked from my CodeIgniter Spark. I converted that OAuth2 Spark from a FuelPHP Cell when I had a project that called for it.


The realisation hit me like kipper to the face. Why are we all sat around building out identical solutions to each other or forking and maintaining seperate codebases when we could just be finishing projects?

I on average spend 70% of my working day on client projects and 30% building or fixing, writing or porting packages and libraries. That 30% could make me 30% richer, or give me 30% more time doing something more interesting than writing code. Maybe I could get around to writing an even BIGGER rant about something else?

Whatever it is we would end up doing with this extra time, we need to find a way to get there.

The PHP community needs to get together behind a new solution and the framework developers need to lead the charge.

The Plan

Two very talented PHP developers (Nils Adermann and Jordi Boggiano) have been working on a PEAR-killer called Composer, which has a single default repository called Packagist. Composer is based on systems like npm (NodeJS Package Manager) and Bundler / RubyGems.

There is another solution called Phark but it's still unfinished and their syntax is horrid. Sorry guys but Phark just doesn't look any good to me - and the website linked from your GitHub repo is giving DNS errors. Moving on.

I am happy to see that Symfony are all over packages like a wet flannel. They have been helping out and a huge number of their packages are now using Composer - they've even been sending in pull requests.

Other well known developers like Ed Finkler and Chris Hartjes who record the /dev/null postcast are behind it too. Check the first episode for some of their reasoning. Ed has a bunch of code on Packagist and I'll be joining him with as much code as I can - such as my NinjAuth multi-provider user authentication system.

More than that I am really happy to say that after talking to the FuelPHP team they are all convinced this is the right way for FuelPHP to go. By removing the different between modules and packages, making pretty much everything into a package and fully supporting the PSR-0 standard of file and class naming, we become fully package based.

FuelPHP will still have Cells, but they will be a Composer package that uses a FuelPHP repository. That means our command line utility will be able to install FuelPHP specific code from the FuelPHP repo, and fall back to generic packages. We'll be amending our Autoloader in 2.0 to support Composer packages, and if there is no FuelPHP autoloader in there (which of course generic packages won't) then FuelPHP will just crack on and find the files, instead of being told where they are. Minor speed loss for full support of generic packages sounds reasonable to me!

Hopefully Laravel, Lithium and anyone developing a PHP 5.3 framework will see the light. Don't build out a new system, don't silo your users, don't waste time building code that already exists and for god's sake stop building un-frameworks.

What Can You Do?

Got a good PHP class? Is it only on GitHub, or maybe it's just sitting around on your blog?

Stop that. Stop that right now. Make it into a Composer package and host it on Packagist. While you're at it add unit testing, set up Travis with a GitHub service hook and show off how stable it is.

This all makes it easier for anyone use your code, so anyone can contribute to it. The more we reuse the same packages, the more pull requests we can expect to see on that same code, which makes it more portable, more extensive, reduces bugs and means we can all spend a little more time working on that side-project that will eventually pay for us to get out of this coding lark, marry a fashion model and move to our private island for an early retirement.

Only half of that plan is far fetched, the other half you can do right now.


Stuart Herbert


There's nothing stopping you making & hosting your own packages that can be downloaded and installed via the PEAR Installer. Unlike Composer / Packagist solution, it's completely decentralised, and there are well over 1,000 packages out there available to consume today. And making compatible packages is dead easy if you use something like Phix.

A Composer that was completely decentralised would be very interesting though :)

Erik Wiesenthal


That's right.
I was using psr-0 and Zend Framework "lib components" to try to mantain some kind of "generic packages" on my code. Triying to port laravel, lithium, fuelphp, codeigniter elements is always a headhache due to multiple dependencies (lot of helpers, dic classes, strange behaviours on autoload....). (even with your codeigniter OAuth spark)
The unique way is to make a compromise, between php comunity members,on a tested, well designed, non outdated package system.
On the other way, there will be always a problem around conventions. At last it seems it until now.
I will give a try to composer.

Andrew Smith


Great post Phil, this is definitely the way to go. I am doing some work on Slim Framework and we have just made this into a Composer for ease of install and to make dependencies a lot more easier to handle. I hope the other frameworks will get onboard so we can have one Package management system for PHP.

@Stuart Herbert - Composer is decentralised, you can actually store your code wherever you want and add in the repository to Composer. You can even use it with PEAR packages. Have a look into it.

Niall O'brien


Great article Phil, I only disagree with one point. I think ORMs should be part of a framework. The reasons you give for frameworks being a great idea (a CI dev will know where everything is etc.), built-in ORM offers the same benefits, without having to possibly switch between different ORMs for different projects. Yes, ORMs are opinionated and will never satisfy everyone, but it's worked well for the Rails community thus far. Glad to FuelPHP adopting this mentality, however, until more hosts support PHP5.3, we're stuck with CI.



Time to unframework..!



Niall: I will fight this point to the death, just because somebody is making a framework does not mean they need to make an ORM.

Sure Doctrine and Symfony were made by the same person, that is absolutely not the point. A framework should work with anything. If you include ORM A then a fan of ORM B is annoyed. If any ORM can instantly work with any framework then you're onto a winner.

All that you need is a "Fuel-Doctrine" package, which will go onto a Fuel-specific channel, meaning that FuelPHP config works with Doctrine. This is an absolutely minimal bit of code, no changes to the codebase, etc. It simply requires Doctrine as a package and so it installs.

Simpler packages will not even require that.

Back to your original point, people want everything handled by the same team. I get it, I do but it is unfair and ridiculous. I build PyroCMS and people want me to build an e-Commerce module. Sure but that means as well as trying to take on WordPress now I am trying to take on Magento? That will slow me down 50% and make the whole project suffer. Then somebody complains that I haven't built a hotel booking system. When does it end?

If a framework developer feels like building an ORM (Jelmer did for FuelPHP) then so be it, great for that guy. But it should be an optional package, which has no preference in the core than any other package.

Erik Wiesenthal


Anyway, needs a voting system. or similar Or it will become a phpclasses filled with ackward classes to manage mysql connections....



Erik: That sounds reasonable enough. One of the benefits of Packagist and Composer is that it's all up on GitHub so anyone can fork it and add improvements. If you spot something that would make it better then get involved.

If you don't feel like a pull request then Jordi is a great guy, so just talk to him. I've had him on MSN for years and he is always helpful when I have feedback for his projects, spot a bug or get stuck.

Niall O'brien


I understand your point and do agree with it to a certain extent. Yes, it is great that the core of a framework, such as CI, is pretty minimal compared to something like Symfony. That's great, it reduces the barrier of entry for new developers and allows maximum freedom with regards to what Sparks you use to help you and your project.
However, what I love about Rails is that generally speaking, the core installation (with AR etc.) is very opinionated, is the acknowledged norm and I know where I can find pretty much everything for that particular application. I can pick up a book on Rails and I will learn the full stack (excluding project specific gems of course).
Hopping from one CI project using Doctrine to another using something like Datamapper is annoying to me. I prefer unity and consistency, not just from a coding and project perspective, but from documentation, tutorials & books etc. but I understand that this is just personal preference. It just so happens that this personal preference is what works really well for a framework such as Rails.
Perhaps FuelPHP is the Rails of the PHP world, which is great, but it's still a bit too early to tell.



Thanks for great post Phil! There are many practical tips for PHP developer. When I coded my first unframework I thought that was the best solution but I wondered why nobody uses it.



Thanks for great post Phil! There are many practical tips for PHP developer. When I coded my first unframework I thought that was the best solution but I wondered why nobody uses it.



Niall: Is seems that most of your argument boils down to "I don't like choice, I want the framework to tell me what to do and I don't want to learn new things". That is how Rails works, but CodeIgniter is the polar oposite of Rails in almost every way. You used the term yourself, "full-stack". CodeIgniter is a lightweight framework, Rails is full-stack. They say "here is EVERY tool you need."

CodeIgniter is more like Sinatra which is a lightweight framework. Sinatra describes itself as ORM agnostic, which is lovely.

You seem to think that Rails has fixed a problem of "learning multiple ORM systems" by having one included. Not so. In the PHP world there are more frameworks and it is more likely that a "PHP Developer" will have to work with multiple frameworks, meaning if they all have their own ORM you are fucked for learning how each one works AS WELL AS learning a new framework.

If the tools such as ORM, Authentication, ACL, OAuth1/2 etc all become framework agnostic then you can take your favourite tools and move to whichever framework you are required to use for a specific project with minimum fuss. If you are taking over another codebase then you have to expect different tools to be used, but if those tools are popular it is not an issue. I had to consult recently on a project using RedBean ORM. I knew nothing about RedBean but they have documentation so I took a few hours to learn and that is information I have forever. I'd rather learn about RedBean - which could turn up in any project - than learn about Laravel's ORM, which is only useful if I ever need to work with Laravel.

Surely that is more ideal than expecting every framework to waste time building similar packages to be shipped in the core, when they could spend that time on something useful.

Calvin Froedge


Good stuff, dude! Stick it to the man = )

Tim Post


I've been working on a lot of interesting things revolving around Redis, Basically ending up with a few CI libraries and a bunch of models. I was just going to dump the whole bunch on Github, with the idea that people would take out whatever they don't want.

Packagist looks like a better way to make them available, as just classes. People could then pick the functionality they want, and get only the libraries needed to make it work. It would then be extremely simple to drop things into whatever framework someone wants. And, well, you should make your code easy for you to re-use, too :) I frequently write micro API's for odd systems so they can be controlled and monitored easier, a framework even as light as CI would be a waste there. In those cases I roll my own (or rather re-use the one I wrote that makes perfect sense to me).

I mostly agree with you regarding Pear, but I sometimes enjoy finding abandoned but almost useful gems in the rough and polishing them up a bit to suit my needs. Still, it is a little painful depending on what you need and how much time you have to get something done.

Alan Pinstein


We took a shot at this packaging problem a while back with Pearfarm. It is essentially a de-centralized PEAR repo, exactly like RubyGems. Others did similar things, like Pearhub, etc. We decided not to re-invent the "installer" part of PEAR because it worked pretty well and it's not a simple thing to do.

On many levels it seems nuts to me that as a community we're re-inventing the "package installer wheel" but I guess although it's not a simple thing to do, it's a *common* thing to do, and the community has managed to do it many times (as have many other communities).

Interestingly, none of us (the distributed PEAR repos) succeeded in getting any traction. I think largely this is because the PHP community doesn't typically distinguish between PEAR the installer and PEAR the repo. The repo part is a disaster, while the PEAR part works pretty well, though it does have issues. However it still has advantages over composer for things like installing executables, etc.

For whatever reason, Composer seems to have gotten much more traction, and certianly that's a good thing.

In any case, I would *love* to see the entire community get all of our packages into a single repo as there are enormous benefits to the community if we can make it happen.

To that end, I would definitely recommend using composer where possible. We are certainly going to try to use it in house.




Yes, you are correct that Flourish still has the beta tag, yet development continues and it still serves a niche that no one else will touch. Specifically proving a base set of packages that run anywhere on PHP5. It actually is pretty close to the definition of a collection of packages you present at the beginning of this post. I just provide a web-based tool for dependency management ( since it is more flexible than a command-line-only solution. :-)

That said, I completely agree that the PHP ecosystem has a broken distribution model. That is the reason there are so many full-stack frameworks out there. I've actually just started work on changing the infrastructure behind Flourish to support Composer. Having a community-run infrastructure for packages that is flexible is a very valuable thing.

Obviously you need some stable base classes so you don't reinvent core things like securely accepting user input, but the more we can spend time on non-trivial problems, the better. The thing I personally would love to see us somehow side-step is the dependency nightmare of CPAN. When it requires 2 hours of time to (automatically) download and install all of the dependencies for SVN::Web, there might be too much tight coupling going on. I'm not sure how exactly to avoid this - partially because the PHP community is both blessed and, at the same time, cursed by backwards compatibility.

And now putting on the rant hat…

The more we can work together and stop re-inventing the core MVC architecture the better, however I've always disliked the notion prevalent among that large PHP frameworks that no one else should waste their time with anything else. There are lots of issues that these projects punt on. Oh, you aren't running the latest PHP stable release with bcmath, mbstring, imap and gd, sorry! Hopefully with a packaging system we'll see more work on tooling beyond another ORM and another controller infrastructure. I think PHP's greatest strength is that is it installed everywhere, so having code that can actually run anywhere is a really nice thing.



It's an laudable effort. But objectively Composer is just the latest NIH package management system. Instead of reusing any of the existing tools, they added a new one. And there's the new JSON meta format instead of just extending something established like PKG-INFO. And as you said, it was conceived as centralized service. Doesn't look like standardization.

As usual I object to the PSR-0 thingy (if you don't comprehend the language semantics, then don't declare standards). And since that's implicited upon by the packaging service, it's not quite unix-y and single-responsibility. And the inordinate amount of code that went into version resolving makes it more likely that it ain't gonna be utilized, or lead to Firefox-esque warnings.

So, I'm sorry to say. But it'd rather wait for one of the WebCMS projects to step forward, generalize and propose their tool as standard. (Rolling eyebrows implied, I'd even use the Wordpress scheme..)

Lachlan Donald


Author of Phark here. Unfortunately I lost momentum with getting Phark built, getting married and moving overseas tends to consume ones spare time. I actually tend to prefer the PHP syntax for declaration, but I can also see the appeal to the Composer json approach.

Ultimately I don't mind which package manager gets there, I just want one that makes it easy for everyone to contribute packages. Phark does some neat things with an autoloading stub in auto prepend, but could do the same with Composer.

My original rant sounded a lot like yours:



Good initiative phil ..
was waiting for some one to make this post..

Definitely composer is the way to go..
even Symfony guys are supporting it..

Mike Funk


+1 for a unified solution!



Lovin' it. A npm-like system (from nodejs) for PHP is just a HUGE win. The future lies in assembling micro-libraries. This is why coding with nodejs is so pleasing.

Greg Militello



I think the ORM discussion (to include or not by default) should be a topic of its own. Even if I like having one bundled, being ORM agnostic is helpful in every case. I love how Symfony allows for Doctrine, or Propel2 or anything if you want it. However that is a discussion for another time.

The rest of your article is well put. (sometimes digging a bit hard on the ZF2 guys, but I don't think they will be too upset).

Might I suggest you also point out things like Symfony's CMF team ( This is a project that IMO should be decoupled from Symfony as much as possible so it could be reused in other frameworks. In fact a lot of the project initiative is fully portable to other frameworks as-is, but it is certainly untested in many cases.

Matthew Turland


One minor correction: it is currently possible to have multiple independent PEAR installations on the same system that don't require root permission to set up. See

That aside, I think the rest of this post is spot on.

Harro Verton



FuelPHP's own composer site will have a comment and voting system a bit similar to stackoverflow.

The PEAR guys had a point when they wanted to get some "quality control" in. Unfortunately peer review doesn't work that well without peers...

Mike Mckee


Something we need is a unified plugin model with an API. Then, all the frameworks can implement that model. At that point, we could build plugins like mad and they would work in all the participating frameworks.

BTW, I've written a framework too: FasterMVC. It now supports plugins and themes.

Hari K T


Great post . And I am glad to hear Fuel will be changing to PSR-0 standard.

As you mentioned, I too was having a thought that everything needs to be in the framework itself when I was looking into .

But later I understood the importance of component based library which has less dependency or no dependency, which we can use it any where or if we want to use a framework as a whole, ie how I joined Aura project.

The current Aura packages has no dependency on any components of Aura itself and is build for PHP 5.4 + , and is PSR-0 compatible. Can also be downloaded using composer .

Source :
Homepage :

Phil Sturgeon


Wbond: Thanks for dropping by. I'm very happy to hear you're moving Flourish over to Composer. I get that a BETA tag doesn't mean much (hell, we were using FuelPHP on production websites when it still had an ALPHA tag) but it doesn't instill much confidence in potential users. People trusted GMail with its BETA tag because... well it's Google!

Still I might have come across harsh on that, but while there is a bunch of great code in there it IS ageing and its hard to keep things up to date while backwards compatible, I get it :)

And yes, I follow you completely with the rant hat. My examples of packages are pretty weak, it's not all about ORM but even low level things like really good NetHTTP style libraries - which both FuelPHP and CodeIgniter could definitely both do with. Ed Finkler has one and Buzz is pretty good too.

Phil Sturgeon


Lachlan Donald: Hey there. Again, my description might have been harsh but I speak figuratively, no time to be nice about everything :) Also, I absolutely understand about moving around and giving up. I went nomadic for a year of traveling and working when I could, without support from the various teams I am part of a few of my projects would be dead too.

Composer using JSON was apparently quite a tough call. Whichever they picked would end up having complaints from fans of other systems - be it YAML, XML, LOLCAT, whatever it is, somebody is going to whine. I definitely think it simplifies things to use any one of those formats, and understand why you'd like PHP for added power - I just don't think a list of dependencies needs that extra power.

The best thing you could do to help ensure PHP gets a decent eco-system - especially if you cannot spare the time to build up your own - is to put a note on the repo marking the end of active develompent, roll any of your awesome features that Composer doesn't have in as a pull request and get behind the new system. The more people support it the better it gets, and the less options there are the less people will complain about having too many options - even though realistically there aren't many.



HA ha selling your own fish, it is NO TIME for it to become PEAR 3 !!



Here is the scoring system for the Symfony2 bundles index:

As you can see it derives most of the scores through metrics fetched from github, but also adds metrics like if the Bundle uses travis etc.

@Greg: Indeed the key piece of the CMF is PHPCR, which we indeed hope to see adopted by other projects and there is a lot of promising discussion by various CMS projects. But whats even better is that one of the first ZF2 modules integrates PHPCR (



I'm confused about the Composer/Packagist plan. From what I understand, the point of it is to create reusable code that can be used anywhere.

But browsing through the packages at Packagist, I see a lot of framework-specific packages (mostly Symfony). How exactly does this solve the following problem?

"The downside is that the same code is being written over and over again for different frameworks, which is a massive waste of man-hours."

It seems like each framework/application would require a wrapper of some sort due to its unique syntax and conventions.

Phil Sturgeon


Jelly: You are seeing a lot of Symfony packages in there because Symfony use it for everything. FuelPHP would of course put its FuelPHP related code in our repo and general code in the general repo, meaning less of this near-spam of content.

Either way, it's about meeting in the middle. If you take a framework exactly as it is and try to jam Composer into it then it will not work entirely. Reliance on custom config classes, custom loggers, etc will stop general code from working. But if you can meet half way in the middle then the package will be less dependant and the framework will be able to load more types of package.

Even if FuelPHP requires a "fuelphp-foo" package just to implement "foo", then thats fine! We write a little bit of code and mark "foo" as a dependent, meaning both get installed. This is how Rails handles a large number of Gems, which otherwise wouldn't work. A little bit of glue is better than "let's write an entire Foo system from scratch because the other framework has a mildly different syntax". That is just messed up.

Kapil Verma


you know what .. i think php needs something like rack (for ex. the symfony2 http foundation) over which components can be built, a unified request response api .. for the new packaging thing in php community to be successful



A related note that Drupal is currently working towards PRS-0 in D8 and using Composer as well as Symfony. Here are a few related issues;

<ul><li><a href="">Namespace strategy for module-provided classes [policy, no patch]</a></li>
<li><a href="">Proposal for unified namespace organization
<li><a href="">Introduce Composer for Symfony component management</a></li>
<li><a href="">Provider based PSR-0 Classes</a></li></ul>

<a href="">PSR-0</a> (all tagged issues)



oh ugh. mods; feel free to hack that formatting and remove this message, ta.



I'm not against anyone "re-inventing" the wheel but where is the collaboration? :)

Your blog post is putting the focus on a very important topic but you manage to water your message with name calling and by flaming projects.

PEAR has been around the longest and what people don't realize when they judge the catalogue: maintaining is hard. This is why we impose relatively strict rules now before we accept packages. It's not like there are no people contributing, in fact there is a lot of peer review going on when a vote is called. Prior to that people are welcome to get in touch by mailing list or IRC.

That's what's currently possible and if people don't like that no one forces them to publish on PEAR. They can just get SimpleChannelServer or pirum and run their own show.

As for the state of software in PEAR – yes, plenty of bugs and not everything is maintained. There are still a lot of PHP4-compatible but we are moving along to find replacements. And by the way, I know that many don't mind recommending a replacement outside of PEAR.

As for alpha, beta and stable – typically we version very, very conservatively because once a package hits 1.0.0 BC breaks are impossible. People rely on many PEAR packages and you cannot expect them to work through "UPDATING" every time they run "pear upgrade". So of course alpha and beta software is more likely to change the API, but if you had done your research (and you haven't), you would know that a lot of software is already very stable despite being early versions.

And speaking of research: – oh, look. Zend Framework uses pyrus (aka the PEAR2 installer).

Anyway – a system like rubygems (or pearfarm, pearhub, composer/packagist) is more a "anything goes" type of thing and look at pearhub or pearfarm. Not exactly deserted, but they gave up already as well.

It's a lot harder for myself to consume software from these sources because versioning and labels don't mean anything. Unless I know the contributors/authors and know how they work, it's next to impossible. A lot of projects start with a 1.0.0 and quickly advance to 2.x and 3.x when they realize that they have to do fundamental changes. If I have to re-integrate software every 2 or 3 weeks because of fundamental changes in the implementation, API or whatever, then it's not suitable for a professional shop.

The biggest problem in PEAR is maintaining old code. People don't (always) understand the importance of BC and of course it's easier for people to desert their own code and move somewhere else and start fresh. I can't really blame them, but that's not the goals of the project.

People also don't want to maintain old code, but lots of people still use it. The state of software is as viable as the people maintaining it. I don't want to put anyone down, but there is dead weight everywhere: rubygems, cpan – you name it. Crowdsourcing by counting github forks and watches only help to a certain extend. Frequent contributions etc. make it worth while and some projects manage that really well.

Anyone in PEAR is interested in meaningful suggestions and collaboration among PHP projects so people do not have to reinvent anything. But if people want to write their own packaging system, they are of course welcome to do it. I know that the composer guys found limitations which they couldn't work around so they did their own thing, but aside from that, I don't know anyone reaching out or discussing these things to improve the state for everyone in PHP. Not just for a distinct project.

And speaking of composer: I find the project very interesting, but I don't see that as a replacement really. More a complimentary solution. I'm also contributing (Get it?) on this project. If you want to look at it in terms of ruby, it's like rubygem and bundler.

Anyhow, it would be nice to discuss these things and talk them over. Find out requirements and how to make it better for everyone.



Nice post, I agree on leaving ORM's out of frameworks... Sparks is good in theory but doesn't work smoothly with a modularized application.

Why not add Composer to CI?

Henrique Vicente


I'm dedicating my time at this beginning of the year to make my main code base better while I adopt good practices such as TDD, etc.

Some days ago I was setting Travis and I saw I had to resolve the dependencies, etc. It was even important for some others who eventually decides to use my project.

So I downloaded composer and tried to use it, but I struggled. I just couldn't find a easy, clean way to install libraries not available trough Packagist or GitHub. My impression is that it is really a solid system, but that it doesn't play well with "legacy distribution" of code. Correct me if I'm wrong. I really want to use it. I don't know if this is by design or not. If it is, I don't have anything to say as I don't know the strategy. If it is not, I think it is something to improve.



Generally I do not post on blogs, - but I would like to say that this post really forced me to do so! really nice post <a href="">Abercrombie UK Sale</a>.



This is the best post I've read about PHP. It puts everything into perspective. I'm working for a primarily PHP company and am so sick of the infinite number of PHP frameworks. Yet couldn't get my head around why other languages seemed so "unified" in their web development efforts.

Thankyou very much!



Great article.

Well despite the word "framework" in the title Zend Framework has been doing this since '05 or definitely '06. Most of it is decoupled and even the MVC is only a VC. Provide your own model. It's not a package system because what is also missed and only briefly mentioned is that the package system is system wide. If it can be on a project per project basis and can update certain projects only, then I can see a good use for it. I could pull out 90% of ZF and repackage it into packages. Then again, do we really need a package manager for that?

The concept of modules in ZF2 are not for reusable code like oAuth but for bigger chunks like a blog. Yes it's all reusable code, but write me a blog component that I can just install with a package manager that will work with my PHP app no matter what framework/no framework it uses. Not doable for things like 'blog,' already done for things like oauth.

Phil Sturgeon


Lucian: It's definitely called "Zend Framework".



Well spoke.
I've enjoyed laravel but learning the ORM is pissing me off.

Whatever happens, make it as simple as "download and unzip" (a la github).

You guys are amazing.

Fiverr Français


You're so interesting! I do not believe I've truly read through anything like that before. So great to discover someone with a few original thoughts on this issue. Seriously.. many thanks for starting this up. This site is one thing that is required on the internet, someone with a bit of originality!



I suggest they could do a category and top10 for each category, and/or tags view. Orelse, it will soon become a garbage bin. I even don't know how to find a useful class...before i know the class name.



Yarco: The website needs some love for sure, but it's all up on GitHub so you're welcome to make any changes you like. I hope to get involved at some point, but everyone is always busy you know how it is.

Amul Patel


package manager for PHP - bout time!



I'm starting to notice the issue with packages. Is there not a well put together set of HMVC modules? Like, a calender system or even an internal messaging system. Never seen one, but I haven't been looking hard.



Ede: You are basically talking about a "universal CMS" which the entire PHP world needs to agree on.

How would the DB connections be handled?
What would the interface look like?
Do we have first_name and last_name or name?
What DB system do we use?
How are permissions handled?
What event system is in use?
Does it use an ORM?

If you could make the entire PHP community agree on a single answer to all of those things then we could do it, but the PHP-FIG will spend 3 weeks calling each other names just because developers cant agree on a prefix or a suffix for class names...

That will never happen.

Also, HMVC has nothing to do with modules - you're getting the two ideas confused :)

Posting comments after three months has been disabled.