The Semi-Official Zend Framework Pear Channel

January 7th, 2009 § 14 comments

Pear Channel?

For the past few months, the ZF team has been playing with the idea of releasing ZF from a PEAR channel. Over the past 2 years, we have seen a few channels distributing ZF that have pop up here and there.. so that lead us to believe there is an itch that needs scratching.

The compelling reason against a PEAR channel is that, with ZF, there is nothing to “install”. Just pop ZF in your include_path and off you go. You could obtain ZF from SVN via export, checkout or externals tag.. or you could download from the website. A PEAR channel (until recently), didn’t make enough sense because copying files from one location to another was all it would be doing.

ZF Grows beyond Component Library

That is … until ZF 1.8 (coming soon to developers near you). With 1.8, Zend_Tool will be going into production. I’ve chatted ( about it, I’ve spoke about it (#zendcon08), and I’ve tweeted about it in recent months. But for those that don’t know, I can sum Zend_Tool up in 3 major aspects of functionality:

  • Zend_Tool_Framework is a dispatch system. While Zend_Controller has the Front Controller and web model hammered down pretty good, Zend_Tool_Framework is an introspective dispatch system for exposing its capabilities via command line (cli), XML-RPC, SOAP, or any other [insert your remoting platform of choice here].
  • Zend_Tool_Project is a profile driven system for managing project related resources and their relationships to one another, the ability to create them, remove them and alter them within the lifecycle of a projects development.
  • Zend_Tool_CodeGenerator is an abstracted system for generating code, including but not limited to PHP. Plans are in the works for generating Apache configuration files, ini and xml configuration files… all wrapped up in an API that is natural and similar to the API’s you’ve already become accustom to inside ZF.

So, that said.. What does this have to do with the PEAR channel? ZF is moving from a library of “runtime components” into more of a holistic framework with capabilities of code-generation, scaffolding, and project management, which complicates the process of installation. PEAR installer is really good at installing code into an already running PHP stack, be it site wide or local. So, by delivering ZF through the PEAR channel, the complexity of installation is shifted off of the consumers and onto the delivery channel.

So what does “installing” mean? It means some elements of the package need to go into some pretty specific areas on your system for them to work correctly. For ZF, it means you will need to put


in your executable path,

in the

directory, and put the Zend Framework inside your

. If you’ve used tools like PHPUnit, PHPDoc, or some other framework, this type of “installation” should make sense to you. If not, go poke around you system after installation to better understand.


So, onto the technical details. If you want to see what it can do, first discover and install:


More information will be posted on as it becomes available (this includes other packages in the channel, and other releases like beta and alpha).

To see Zend_Tool in action:


Now, go explore the project that was created. In addition to that, you can also run “zf show profile” and it will generate a tree of your project. There will be more updates, and more providers available in the coming weeks to show off what we’ve been developing for Zend_Tool. Also keep Zend_Application in mind because as it formalizes, it will be the target of what we will be generating from Zend_Tool and the zf command line interface.

Details, Details, DETAILS!

Like mentioned previously, the pear channel is beta. What could be beta about it you ask? Well for one, the package and release plan that comes along with it. As of this writing, here is the plan:

  • ZF Package
    • Stable (no version modifier)
      • source: tag
      • schedule: on tag
    • RC – Release Candidate
      • source: tag
      • schedule: on tag
    • Beta (beta)
      • source: branch of current release branch
      • schedule: weekly
      • version: current + 1 mini
    • Alpha (alpha)
      • source: trunk
      • schedule: weekly
      • version: current + 1 minor
    • Development (devel)
      • source: trunk patched with selected incubator components
        • maintained in a file in incubator (locally for now)
      • schedule: weekly (or on demand)
      • version: current + 1 minor
  • ZF_Minimal Package
    • (scheme same as above)
    • Source modified
      • no tests
  • ZF_Extras Package
    • planning
  • ZF_Laboratory Package
    • planning
  • ZF_Doc_Lang Package (maybe)
    • planning

This might get tweaked over time, but the idea is pretty solid. Stable comes from tags as well as release candidate (and patch releases if they exist, not mentioned here). Betas are considered the next mini release, and alphas the next minor release. Development is super developmental, as you can see as its cut from trunk with selected incubator components.

More details will be forthcoming as I’m sure there will be questions you might have that are in search of answers. Till then…

Happy ZF-ing!

Tagged ,

  • Bradley Holt

    Very interesting! Next to Stable in parenthesis you said “no version modifier”. With the ZF 1.7 release there was a PHP version requirement bump which means that those running older versions of PHP (like those on RHEL5) will have to stick to ZF 1.6. Will there be a way to “lock” into a specific minor release for situations like this?

  • ralphschindler

    Well, the package.xml file will be able to require specific versions of PHP, if they are not met, then the update will show a notice and not continue. In situations like the redhat one, we are hoping that they improve their ability to stay up to date with stack components like PHP (same with debian).

    With pear, you are always allowed to install a specific version, so for example, pear install zfcampus/zf-1.8.0 even if 1.9.0 is marked as the stable version.

    I’ll have a new article coming out that will explain a bit more about versioning, what it means to ZF-PHP projects/applications and casual scripts.


  • Ralph Schinder’s Blog: The Semi-Official Zend Framework Pear Channel : Dragonfly Networks

    Ralph Schinder’s Blog: The Semi-Official Zend Framework Pear Channel
    Ralph Schinder has posted about a new development in the world of Zend Framwork distribution – a PEAR channel.

  • Wil Sinclair

    There is a very important footnote I’d like to add to all of Ralph’s good work. While the focus of 1.8 will be RAD tools which provide much of the functionality that most people consider criteria for a ‘framework’ nowadays, we are hardly abandoning our use-at-will and component-library-like architecture. In fact, we intend to show how a project can function both as a component library and a framework without compromising on either aspects. The very components that implement the RAD tooling (Zend\_Tool and Zend\_Application, so far) will be use-at-will themselves. These simultaneous ‘component library’ and ‘framework’ aspects will form a duality in the ZF project going forward and all design decisions should accommodate both.
    That said, for most of you this is not an important point. After all, if ZF works well for you, who cares what we call it? :)


  • Zend Framework in Action » PEAR channel for Zend Framework

    … PEAR channel for Zend Framework”>PEAR channel for Zend Framework Ralph Schindler has created a semi-official PEAR channel for Zend Framework. If you like installing via PEAR, then check out

  • Zend Framework poprzez PEAR | Micha? ?wito?

    …(0) Jak donosi Ralph Schindler na swoim blogu ju? teraz mo?na pobra? z pó?oficjalnego kana?u PEAR nasz ulubiony Framework PH…

  • darkangel


    That’s so good to hear! Having both options is the *perfect* solution in my opinion.


    I think the response previous to mine is causing issues with the comment form.

  • Brandon P

    PEAR is great but (correct me if I’m wrong) it doesn’t allow you to install and keep multiple versions of the same package.

    If you have a server that hosts multiple applications each application may require specific versions of an individual class installed via PEAR. What happens if “ApplicationA” requires 2.0 but “ApplicationB” is designed around 1.8?

    Personally, I don’t want to have to worry about “Will my application that is designed for 1.8 work under a new version”?

  • Derek Martin

    Great to hear!
    I’ve used those PEAR channels, but they always died off :(

    >> ZF is moving from a library of “runtime components” into more of a
    >> holistic framework with capabilities of code-generation, scaffolding,
    >> and project management, which complicates the process of installation.

    Complicates it entirely, or only for those wishing to use the Application/Tool part of the Framework?

    One of ZF’s selling points has always been “You can use just 1 piece, or a few, or all of it. Take what you want.”

    Does this transition mean that statement will no longer apply?

    >> @Will – we intend to show how a project can function both as a
    >> component library and a framework without compromising on either

    Hope it can still KISS

  • ralphschindler

    Hey Derek,

    The ZF will always be a “use at will” architecture. The only part that is “complicated” is getting the zf.php script (the command line client for Zend_Tool) in the correct place and utilizing the ZF library.

    The rest of ZF is the same as it ever was, and if you dont want to use any part of the zf.php command line tools or anything from the Zend_Tool component, you are free to do that :)

    The purpose behind the pear channel here it to be able to use a pretty well known distribution medium (PEAR), to get all the proper tools “installed” in your systems PHP environment. No more, no less.


  • John Kleijn

    I never understood the reluctance of ZF to create an official PEAR package. Sure, it is more a lib than what it is traditionally considered a “framework”, and that is its strength indeed, but why is that an objection? Zend Framework itself may not have any dependencies on other PHP software (although I hope adding optional support for 3rd party software becomes a trend with the framework), there are people who would like to build software dependent *on* zf, and a package manager facilitates that. Package managers in linux have hundreds if not thousands of library packages which require no more than “copying files from one location to another”. That’s not the only worth of a package manager.

    Perhaps if Zend officially endorses a ZF channel, not just focussed on Zend_Tool, more OSS based on ZF will sprout. And that can only be a good thing, because 90% of OSS PHP apps out there now complete and utter crap (although granted those usually are not written on PEAR components). Also this channel could be better managed (automagically?). The current stable in the channel is 1.8.3, while the current tag is 1.9.1..

    Maybe stating the obvious, but then again..

  • Amr Mostafa Youssef

    Just wanted to drop my thanks, this is really helpful. I’m now using this on our production servers.

  • Pingback: The Semi-Official Zend Framework Pear Channel | Zend Framework University()

  • sam

    arggh. zend tool – way to shorten ZF user base to linux users only :) Biggest marketing mistake Zend has ever made.

What's this?

You are currently reading The Semi-Official Zend Framework Pear Channel at Ralph Schindler.