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]> 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]>] >> >> *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/>* >> >> >> >> ----- Original Message ---- >> From: Wil Sinclair <[EMAIL PROTECTED]> <[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 >> >> >> >> > > -- View this message in context: http://www.nabble.com/ZF-Packaging-tp15027830s16154p15037534.html Sent from the Zend Framework mailing list archive at Nabble.com.
