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 (#zftalk.dev@freenode) 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 zf.sh or zf.bat in your executable path, zf.php in the php_bin directory, and put the Zend Framework inside your include_path. 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.
Details
So, onto the technical details. If you want to see what it can do, first discover and install:
(discover the zf channel)
/my/path# pear channel-discover pear.zfcampus.org
(install zf-devel)
/my/path# pear install zfcampus/zf-devel
(or for something stable)
/my/path# pear install zfcampus/zf
More information will be posted on http://pear.zfcampus.org as it becomes available (this includes other packages in the channel, and other releases like beta and alpha).
To see Zend_Tool in action:
/my/path# mkdir tmp; cd tmp;
/my/path/tmp# zf create project
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
- ZF_Extras Package
- ZF_Laboratory Package
- ZF_Doc_Lang Package (maybe)
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!
