Thanks for bringing that up, Simone. That page is out-of-date at this point and it needs to be updated. I haven't gotten to this yet because I wanted to replace it with a real FAQ that is current but I haven't found the time. I will try to do something with that page- possibly just archive it- later today.
,Wil From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Simone Carletti Sent: Sunday, January 27, 2008 6:07 AM To: Wil Sinclair Cc: [email protected] Subject: Re: [fw-general] ZF Packaging AFAIK, an unofficial PEAR channel for Zend Framework has already being created at http://code.google.com/p/zend/ Wil, I don't know if you noticed Zend Framework FAQ page talks about an official(?) PEAR channel at http://pear.zfdev.com/ http://framework.zend.com/wiki/display/ZFUSER/Frequently+Asked+Questions Additionally, http://pear.zfdev.com/ is no longer available. I think this information should be removed. Do you agree? Simone On Jan 23, 2008 8:42 PM, Wil Sinclair <[EMAIL PROTECTED]> wrote: In any case, there are- and almost surely will always be- those users who won't want to use PEAR, and we will continue to make the installation process simple for them. At this point it seems that the best option is a tarball with possibly some CLI support for downloading some optional code/data. We do appreciate the distribution/versioning/dependency management issues in general packaging systems, and we certainly wouldn't take on something this ambitious at this point. We'll only add support for minimal distribution capabilities to the CLI if we can simplify requirements for a ZF-specific setup in a way that doesn't have nasty side effects or gets us in to dependency hell. Hope that sheds some light on the issue from our side. ,Wil From: Kevin McArthur [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 23, 2008 9:11 AM To: Pádraic Brady Cc: [email protected] Subject: Re: [fw-general] ZF Packaging No time for a big rant today, 1. No versioned/split sub-packages. (decided long ago) 2. Versioned paths in pear breaks pear standard operating method. May be confusing for that reason. Pear Upgrade ZendFramework _must_ be avoided if it will change files to newer functional versions. 3. How would you deploy security fixes to existing version releases. 4. There has been talk/work on a CLI tool for bootstrapping anyway, just seems installation would be a natural extension as one command could download/install and bootstrap to prevent any pathing problems. K Pádraic Brady wrote: To remark on some of the PEAR FUD. PEAR doesn't remove the ability to download, decompress, copy and otherwise manually manage the source code - essentially it just takes a default action of downloading, decompressing, and copying into the /php/pear directory which should already be present on the PHP include_path in php.ini which alleviates one more include_path search for those getting a bit worried about having >2. The proposed download archives for Core/Extras/etc. can merrily continue their existence. They wouldn't even share the same subdomain... Does it preclude path versioning? I can script an entire PEAR system into existence using Phing based on any array of preferred version numbers - especially since PEAR does allow you to force installation of one specific version irrespective of it's status or age. Last I checked the basic PEAR installed in under 5 minutes. There is also version compatibility control built into PEAR since you can set a preferred-version on all dependencies package by package. This means control over specific preferred versions for any remote system is a doddle. The only manual intervention would be changing the include_path for the application... Finally, the ZF is a componentised framework - not a fragile stack of cards that will fall apart in PEAR - everyone did quite a good job of ensuring classes/components are decoupled. I would agree that at a minimum there would have to be a Core package of say the MVC components to form the basic installation base for immediate use - everything else could be made a self-contained package available across PEAR, with aggregated commands to install specific "bundles" of packages (perhaps reflecting the proposed download split). Then one could: pear channel-discover pear.framework.zend.com pear install zend/Zend_Core pear install zend/Zend_Services_Flickr pear install --force zend/Zend_Pdf-1.1.2 Not saying the PEAR route is any easier than whatever CLI option Will is considering - but PEAR does have the advantage of being in this distribution business for long enough to learn substantial lessons. The main disadvantage is packaging everything to start with - not a simple task and something for whoever maintains the current ZF build.xml to look into. At the moment for Phing, I'm leaning on work from Travis Swicegood who wrote a lean and mean PEAR packaging task for Phing over on pear.domain51.com. Best regards, Paddy Karl Katzke wrote: A better example might be Python Eggs. You can unpack them to a directory of your choosing using a simple CLI-bootstrap file. Symfony does use Pear, but Symfony is not very shared-hosting friendly -- and Zend *is* shared-hosting friendly, which is something that I would very much like to see the community maintain. -K On Jan 22, 2008 6:12 PM, Kevin McArthur <[EMAIL PROTECTED]> <mailto:[EMAIL PROTECTED]> wrote: -1 from me on this idea. Pear updating something as fragile as the framework could cause all kinds of serious problems for sites using it as a shared library. It would be better to have a cli tool for framework installation.. a web installer like go-pear would probably be a better format for this. I'd also still continue to advocate when using a shared library approach that people use a versioned installation path like /usr/share/php/ZendFramework/ZendFramework-1.5 such that bootstrap files can pick their target versions explicitly. Kevin Wil Sinclair wrote: Actually, I'm a bit ignorant since I'm a relative PHP newbie, but let me turn that question around- why would a PEAR channel be a good way to distribute ZF? That is, considering the current ZF installation is basically download, decompress, and update include path, what does PEAR bring to the table that I'm missing? ,Wil *From:* Bryce Lohr [mailto:[EMAIL PROTECTED]<[EMAIL PROTECTED]> <mailto:[EMAIL PROTECTED]> ] *Sent:* Tuesday, January 22, 2008 2:13 PM *To:* [email protected] *Subject:* Re: [fw-general] ZF Packaging I second the request for PEAR channel. Is there any reason why that would not be a good way to distribute the framework? Regards, Bryce Lohr Pádraic Brady wrote: *Hi Will, It sounds good - an optional lean package would frighten off far less prospective users who have heard tales about HDD's dying from the strain of downloading the ZF ;). I would still like to see a PEAR channel emerge at some point though - that may be a fanciful concept but I gather from the last paragraph something along those lines is under consideration? Hope someone comes up with colourful names for these variants! Best regards, Paddy* *Pádraic Brady **http://blog.astrumfutura.com http://www.patternsforphp.com OpenID Europe Foundation <http://www.openideurope.eu/> <http://www.openideurope.eu/> * ----- Original Message ---- From: Wil Sinclair <[EMAIL PROTECTED]> <mailto:[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <mailto:[EMAIL PROTECTED]> To: [email protected] Sent: Tuesday, January 22, 2008 8:36:39 PM Subject: [fw-general] ZF Packaging As part of the 1.5 release process, we've been reviewing the size of our distribution package and what contributes the most weight. We've determined that there are a few 'heavyweights' that we currently have in the zips/tarballs that many- if not most- users will never need. These include the unit tests, the demos, and the locale files (currently consuming ~8MB uncompressed on my hdd :O). With these components, the 1.0.3 release is ~5.3MB compressed on my hdd. We would like to distribute, starting with the 1.5 RC1, a 'lean and mean' ZF package alongside the 'everything' package. The 'lean and mean' package would not contain the tests, demos, locale files, or extras. 'Everything' would include, well, everything- even docs in html format. To facilitate access to the omissions from the 'lean and mean' release, we would provide a download action for the CLI tool so they can be retrieved and installed in the correct place with a single command. Thomas can give more details about how the locale-aware components would behave in this proposal. Thoughts? Thanks. ,Wil
